Tenure — Instructions for Use

1. Why this document exists

Under Article 3(12) of Regulation (EU) 2024/1689, a system's intended purpose is "the use for which an AI system is intended by the provider, including the specific context and conditions of use, as specified in the information supplied by the provider in the instructions for use, promotional or sales materials and statements, as well as in the technical documentation". It is therefore not a matter of private intention: it is an evidentiary construct built from documents, and this is the principal one.

Two consequences follow, and both are the reason this document was written before the product:

• A formal Article 13 obligation attaches only to high-risk systems. HighKnow's position is that Tenure is not one. This document is written anyway, because its evidential function does not depend on whether it is required.
• Every sentence here may be quoted back. It is drafted so that no verb of assessment is applied to a person anywhere in it.

HighKnow's position under the AI Act. HighKnow classifies Tenure as outside Annex III, point 4(b). Tenure is a meeting aid for the person using it: no person can be the subject of a query, it infers no emotion, and these instructions forbid using it to evaluate or monitor employees. The intended purpose in section 2 and the prohibited uses in section 3 are the evidence for that position. A customer that used Tenure to assess its own sales staff would turn that use into a high-risk one and would become its provider (Article 25); inferring emotions in the workplace is prohibited outright (Article 5(1)(f)).

Status. This is version 1.0, in force from 26 October 2026 and published with the terms of service and the data processing agreement, which carry its prohibited uses (terms, section 8.2) and its Article 25(2) specification (section 4 below; the DPA, section 13) into the contract. Where this document states a behaviour, the reference data protection impact assessment HighKnow supplies to customers carries whether that measure is built, and is the newer document where the two differ. This document is versioned against the product and is revised when the product changes; a stale instructions document is evidence of a system no longer shipped.

HighKnow's own position. HighKnow publishes this version on positions it decided and recorded with their reasoning. On the AI Act classification above, HighKnow's assessment (27 October 2026) holds Tenure outside Annex III point 4(b) on conditions this version states: questions about a member of the organisation are refused (section 5), managers get no per-person output (section 5), and sharing a colleague's meeting to assess them is a prohibited use (section 3). Version 1.1 (27 October 2026) added those conditions.

This document does not warrant compliance for any deployer. A deployer's own obligations are summarised in section 8 and are the deployer's to discharge.

2. Intended purpose

Tenure is a desktop application for business-to-business salespeople: a meeting aid for the person using it. Its intended purpose is:

Real-time retrieval of information from the customer's own knowledge base, and post-meeting extraction of typed factual claims about organisations, deals and commitments, to support the person using Tenure during their business conversations.

Tenure transcribes meetings the user takes part in, extracts factual claims about organisations and commercial arrangements, and surfaces short advisory notes to that user during the conversation.

Output is advisory text addressed to the user. It is not a determination, score, rating or assessment of any person, and must not be relied on as one.

3. Prohibited uses

The following uses are prohibited. They are outside the intended purpose, and a deployer that adopts one may become the provider of a different system (see section 4). They are part of the contract: the terms of service, section 8.2, binds the customer and every member to them.

Employment and worker management

• Performance management, evaluation, appraisal, ranking, comparison, scoring or discipline of employees
• Decisions on promotion, termination, remuneration or any term of a work-related relationship
• Allocation of tasks based on individual behaviour or personal traits
• Monitoring of employees, including monitoring of activity levels, meeting volumes or working patterns
• Recruitment, candidate screening or candidate assessment
• Sharing a colleague's meeting, transcript or claims with another member in order to assess or monitor that colleague; asking Tenure questions about a colleague's performance or behaviour

Inference about people

• Inference of emotions, intentions, or any internal state of any person — including the system's own user
• Coaching or feedback based on how a person speaks — pace, tone, hesitation, interruption — rather than on what was said
• Characterisation of a person's traits, credibility, sophistication or seniority
• Person-level probability outputs. Deal-level likelihood is within the intended purpose; the likelihood that a named person will act is not

Identification

• Biometric identification of any person
• Building, storing or matching voice templates

Consent and jurisdiction

• Use where any participant has not been informed as required by section 8
• Use in a jurisdiction where recording by a participant is unlawful absent consent, unless that consent has been obtained and recorded
• Use in respect of a person who has objected

4. Specification under Article 25(2): the system is not to be changed into a high-risk system

The Supplier specifies that this AI system is not to be changed into a high-risk AI system within the meaning of Article 6 of Regulation (EU) 2024/1689. Modification of its intended purpose, including any use for the monitoring or evaluation of the performance or behaviour of workers, or for decisions affecting work-related relationships, is prohibited. The Supplier does not provide, and is under no obligation to provide, technical documentation, information or technical access in support of any such modification.

A deployer that modifies the intended purpose such that the system becomes high-risk becomes the provider of that high-risk system under Article 25(1)(c), with the corresponding obligations under Article 16, conformity assessment, CE marking and registration. Article 25(2) provides that the initial provider's duty to cooperate with the new provider and hand over documentation "shall not apply in cases where the initial provider has clearly specified that its AI system is not to be changed into a high-risk AI system". The paragraph above is that specification.

(Article 25 read from EUR-Lex, CELEX 32024R1689 as amended by Regulation (EU) 2026/1744; 25(1) is unamended and 25(2) retains this carve-out in its amended form.)

The specification is mirrored in the contract: the terms of service, section 8.2, and the data processing agreement, section 13.

5. What the system does not do

Stated affirmatively, because absence of a feature is easier to verify than absence of an intention.

6. The three documented exceptions to the query rule

Each is person-keyed by necessity. They are stated here rather than left to be discovered.

1. Billing. Seat assignment and entitlement only — no activity, duration, volume or timing metrics. Usage reporting to administrators aggregates to organisation level.
2. Export at termination and legal hold. Available as the organisation export: an owner, and only an owner, prepares and downloads it from the plan page as a versioned archive of JSON Lines files, kept for 7 days once prepared (#655). Asking for it and each download are written to the organisation's audit log. It is self-serve for owners and no other role; it carries the whole organisation as the owner may see it, never a selection keyed on a person. The deployer decides who may hold the owner role and documents why an export was taken.
3. Data-subject rights machinery. Access requests retrieve by person by definition, and honouring an objection requires a suppression register keyed to the objecting individual. Both live inside a named, audited, rate-limited path. This is rights machinery, not retrieval.

7. Data flows

Anthropic is not a separate sub-processor: the Claude models are consumed through Vertex AI, so Google is the processor of record for that inference. The authoritative list is the public sub-processor list and Annex 3 of the data processing agreement. A change is announced there and by email to organisation owners 30 days before it applies.

Residency, stated at the accuracy it can be stated at: all customer data is stored exclusively in the EU, except what is written to the contact@highknow.ai and privacy@highknow.ai mailboxes, whose host offers no choice of data region (the table above; DPA, section 10.3). Request processing is performed in the EU, or where network routing requires otherwise, under GDPR Chapter V safeguards. The stronger statement — that all processing occurs in the EU — is not accurate and is not made.

Retention: transcripts 90 days by default, configurable per organisation up to a ceiling of 24 months with a recorded justification. Extracted claims are retained indefinitely under decay and supersession rules, with a minimal source quote. Audio is not retained by the Supplier.

The transcription sub-processor's terms are signed. Soniox's data processing agreement (version 1.3, signed 2026-10-26) provides that audio and text are not stored by default, and Tenure configures no storage; that customer data is not used for training; and that processing stays in the EU except limited processing for security, support and legal compliance. Soniox holds SOC 2 Type II and ISO/IEC 27001. The transcription sub-processor changed on 2026-08-14; the earlier vendor's published positions do not describe the current one and have not been carried across.

Two vendor facts the Supplier has not confirmed in writing, stated because they bear on the end-to-end data flow: the inference provider's abuse-monitoring retention and zero-data-retention configuration; and what Cloudflare AI Gateway retains and caches, and where. Until each is confirmed in writing, statements about the end-to-end data flow are limited to the Supplier's own systems and its signed agreements.

8. Deployer obligations

The deployer is the controller for meeting content. The Supplier is a processor under the data processing agreement. These obligations are the deployer's and cannot be discharged by the Supplier:

• Lawful basis for processing meeting participants' personal data. The deployer chooses it as controller, usually legitimate interests, with a documented balancing assessment
• Information to participants, in the calendar invitation before the meeting and by announcement at its start. The Supplier provides the mechanism — a layered notice for the calendar invitation, a scripted verbal announcement that names the organisation, a hosted participant notice, and a stop-and-delete control. The disclosure cannot be skipped in the product, and one consent flow runs everywhere, whatever the jurisdiction; the deployer must use it. Nothing is captured before the announcement has been made and no one has objected (section 8.1)
• Late joiners. The deployer must have its users repeat the announcement whenever someone joins after it was made, using the product's control for it ("Read the announcement again")
• Consent where the jurisdiction requires it. Recording by a participant is a criminal offence in some jurisdictions absent the agreement of every speaker; in Germany, §201 StGB makes recording private speech without it a crime. The product's flow is built so that this agreement can be given by conduct: the recording is announced before it starts, anyone can object at any time, and an objection stops the recording and deletes it. The flow is supplied and runs by default; the deployer must not disable it
• Data protection impact assessment. Mandatory for processing of this shape, and the deployer's duty as controller. HighKnow supplies a reference assessment on request at privacy@highknow.ai
• Employee representation. Works council or equivalent involvement is required in several jurisdictions on a test of capability rather than intention, so this product engages it. It is the deployer's duty as employer. HighKnow supplies an information pack for Belgium (CBA 39), France (CSE), Germany and the Netherlands on request at the same address
• AI literacy. Article 4 of Regulation (EU) 2024/1689, as replaced by Regulation (EU) 2026/1744, requires providers and deployers to "take measures to support the development of AI literacy" of staff and others dealing with the operation and use of the system, taking account of their knowledge and the context of use. It expressly does not require a deployer to guarantee any specific level of AI literacy in any individual. It has applied since 2 February 2025 and is not limited to high-risk systems

8.1 What the system does when a participant does not agree

Stated here because a deployer cannot supervise a control it does not know exists.

Local-only capture and a suggestions-only mode are not offered. An objection stops the recording (Off). No client continues after an objection, whether with the user's own speech or with suggestions only.

Nothing is captured before the announcement. The user reads the announcement from the product, waits for objections and taps "No one objected — start recording". Until then the recording strip shows "Waiting for the announcement" and no audio leaves the computer. Capture starts at that tap, and the record keeps the version of the words read and the time. "Someone objected — stop and delete" stays on the recording strip for the whole meeting and takes two taps: it stops capture and deletes that meeting's transcript and the claims drawn from it. A deletion that cannot reach the service at once is retried until it is done, within the 30 days the participant notice promises. "Read the announcement again" reopens the same words for anyone who joins later, and its answer reads "No one objected — keep recording". The plain "Stop recording" control ends the recording and keeps what was captured.

If local-only is ever introduced, it will carry three conditions, and they will never be relaxed. The user chooses it — it is never an organisation's policy and never an automatic fallback. It is disclosed to the other participants as its own question. And the claims it produces are scoped to that user, not to the organisation. Recording one side of a conversation whose other party declined still captures that party's information through paraphrase; these conditions are what would make the mode defensible. It would also require headphones, for a measured reason: on built-in speakers the microphone hears the computer's own output at roughly −10 to −20 dB, which a speech-recognition model transcribes well, so capturing "only the local channel" on speakers still records the other party, intelligibly. It would be announced as a change under the change notice in the terms of service (section 15).

Agreement is never detected from speech. The user attests that the announcement was made and no one objected; nothing is recorded before that attestation, so the attestation is the evidence. Automatic detection would risk manufacturing an agreement that was never given.

8.2 A participant's objection

When the deployer records a participant's objection made after a meeting and names the meetings concerned, HighKnow removes, within 30 days, the transcript of each named meeting except the parts confirmed as spoken by someone else, and the claims that rest only on it; a claim also supported by another meeting keeps that support. Because a far-end speaker is not identified by voice, this removes the user's and other unconfirmed speakers' words in those meetings too, and clears their summaries. From the moment the objection is recorded, nothing about that person is used to ground a card, an answer or a claim. The deployer must not record the person again. HighKnow proves this removal on a real recording before Tenure's first external release.

8.3 One processing operation a deployer should plan for

Where attribution is ambiguous and a person-scoped claim needs a speaker, the user is asked to identify that speaker — including, for a counterparty, by adding a contact record for a person who has no relationship with the deployer or the Supplier. That step is a processing operation in its own right: it belongs in the deployer's record of processing activities, and it is the natural moment at which the deployer's Article 14 duty toward that person crystallises. The Supplier's position is that attaching the notice at that point is the cheapest way to discharge an obligation that is otherwise easy to miss.

9. Human oversight

The system produces advisory text for a single user, in real time, during a conversation. There is no automated decision-making producing legal or similarly significant effects.

The user is expected to exercise judgement over every output. The interface is designed to support this: advisory notes are dismissible, rate-limited, carry the source quote that produced them, and are never presented as a determination.

9.1 AI-generated output is marked

Text the system writes with a model is marked as AI-generated, in two ways (AI Act Article 50(2)):

• Visibly. The label "AI-generated" ("Généré par IA") appears beside the advice on an advisory note, on Q&A answers, on meeting summaries, on the claim list and the review queue, and on thread rollups, for every reader including the recipient of a shared page. On an advisory note it appears only once the user opens the note, never on the short line that is always on screen.
• Machine-readably. Every response or export that carries such text includes the field "aiGenerated": true on the object that holds the text. A deployer or integrator that stores or forwards that object should keep the field with it.

Source quotes and transcripts are not marked as generated: they reproduce what was said.

10. Known limitations

Stated plainly, because understating them in this document is worse than the limitations themselves.

• Transcription accuracy varies by language, accent and audio conditions. Tenure supports meetings in English and French. Word error rates have been measured on read-aloud benchmark audio in each; those figures are not representative of meeting conditions, and no conversational or noisy audio has been measured. Non-native accents, code-switching within a meeting, and poor audio all degrade accuracy.
• Non-uniform error rates are a fairness issue, not only a quality issue, in a system that records what people are taken to have committed to. Per-accent performance has not been measured, so the Supplier makes no statement about it. Per-language performance is measured, and the Supplier will publish it in release notes from Tenure's first external release.
• Extraction is imperfect. Claims record what the system determined was said. They are not verified facts, and a claim may be wrong because the speech was misheard, the statement was misattributed, or the meaning was misread.
• Claims carry a confidence value and a source quote. Both exist so that a user can check rather than trust. A claim should not be relied on without reading its quote.
• Speaker attribution can be wrong, particularly where several people share one audio channel or where acoustic conditions are poor. The local attribution mechanism has been verified in simulation only, against a synthesised two-channel signal; no real two-channel recording has been tested and the decision margin has not been chosen.
• A colleague who takes part without running the system is still recorded, and can be misattributed. A colleague in the same room reaches the microphone channel and looks like the user; a colleague dialling in separately reaches the system-output channel and looks like the counterparty, so a statement they made can be recorded against an organisation they do not belong to. The system compares calendar attendee domains against the participants it can see and warns before the meeting where this is possible, and it is specified to attribute to "unknown" rather than guess — but the deployer should treat a meeting with unregistered colleagues as one where attribution is unreliable.
• Two colleagues in one room must declare that they are. The declaration designates one device as the room's capture and drops the other microphone; without it, both devices record both people and the transcripts overlap. The system may suggest the declaration but does not make it.
• The overlay is visible in screen capture on macOS. No public API prevents this, and the failure has been confirmed on real hardware rather than inferred from documentation. The system is specified to detect the condition at runtime and adapt what it displays, but the user must use the supplied controls when sharing a screen.

11. Configuration and the deployer's instruction

The deployer configures: which claim types are active, retention within the published range, claim visibility defaults, and consent policy. The deployer's configuration constitutes its documented instruction to the Supplier for the purposes of the data processing agreement, and is recorded with a change log.

Defaults are minimal rather than maximal. Where a deployer widens a default — for instance retention above 90 days — a justification is recorded at the time of the change.

Which claim types are active is set by an owner or admin on the "What is extracted" page. Every type is listed with a one-line description. Two types describe an aspect of a named person — a person's role in a deal and a person's stated preferences — and are off unless the deployer turns them on; every other type is on by default. Extraction produces only the active types, from the next meeting or document after a change, and nothing already extracted is deleted by turning a type off. Every change is written to the organisation's audit log as claim_types_change, naming who made it and the settings before and after; that entry is the change log of the instruction.

12. Version and change log

Intended purpose is assembled across documents and over time, so this log is part of the record.