Legal assessment input: expertise-aware assignment ​
Draft for legal review — not legal advice. This document collects facts, design decisions and a preliminary analysis as input for counsel. It requires sign-off by counsel and, for German tenants, the works council before the feature is used beyond internal evaluation (shadow mode). Legal statements below are working hypotheses with sources, not conclusions.
Status: draft (2026-10-12). Design decisions: ADR-0014. A works-agreement template is in betriebsvereinbarung-anlage.md.
1. Intended purpose and concrete effects ​
Intended purpose (proposed wording for the instructions for use): "Quavon assignment suggests reviewers for pull requests and assignees for issues in a software repository, based on the relationship between people and the code affected (code ownership, recent changes and reviews of the same files), their current number of open assignments and their declared availability, in order to route work to people who know the code and to spread knowledge. It does not evaluate the performance, behaviour or personal characteristics of people, and it must not be used for decisions on hiring, pay, promotion, termination or performance appraisal."
| Aspect | Behaviour |
|---|---|
| Trigger | PR opened or marked ready for review; issue opened or triaged |
| Output | Up to count candidates, each with a short list of factual reasons ("explanation facts") |
Mode suggest (default) | Candidates shown in the dashboard and optionally as one comment on the PR/issue; a human assigns |
Mode apply (opt-in) | Quavon requests the review / sets the assignee through the GitHub API; humans can change it at any time |
| Learning | Manual reassignments within a window adjust per-repository factor weights (bounded) |
| Who is affected | Repository members and collaborators who can be requested as reviewers or assignees; in company repositories these are mostly employees or contractors of the tenant |
Concrete effect in the employment relationship. A suggestion or automatic request changes who receives a review or issue, which is allocation of work. In apply mode the system performs the allocation itself, subject to later human correction. In suggest mode a human decides, but the suggestion can still steer the decision in practice (anchoring). Across many PRs, the system also influences who gains experience in which parts of the code base. Recommend-only is therefore a mitigation, not an exemption.
2. Data used and data excluded ​
| Used (code-artefact relationships and current state only) | Source | Stored |
|---|---|---|
| CODEOWNERS entries matching affected paths, team expansion | Repository file, GitHub teams API | Derived ownership per path, refreshed on push |
| Commits and blame lines on affected files (author, path, date), time-decayed | Git history | Per-path familiarity cache (no per-person totals) |
| Review history on the same paths (who reviewed or commented, date) | GitHub API | Per-path familiarity cache |
| Who closed or fixed similar issues (linked PR authors/reviewers) | Issues, PRs | Not stored beyond the request |
| Open assigned issues and pending review requests (count) | GitHub API, live | Short cache only |
| Availability: GitHub "Busy" flag, manual OOO, ICS feed reduced to from/to of OOO events, optional working hours/time zone | GitHub, user input, ICS | from/to only; never titles, attendees or descriptions |
| Opt-out and privacy flags | User and admin settings | people privacy flags |
| Explicitly excluded (must never be an input, output or stored derivative) |
|---|
| Performance scores, ratings or rankings of people; review or merge speed, turnaround or response time per person |
| Quality signals per person: findings on a person's PRs, acceptance or dismissal rates of their reviews, reverted commits, bug attribution |
| Volume metrics per person: lines of code, commit counts or frequency as a standalone value, activity time-of-day |
| Personal traits or characteristics: seniority, age, gender, nationality, language, health, union membership, inferred personality |
| Calendar content: titles, attendees, locations, descriptions; reasons for absence |
| Per-person learned parameters (e.g. "how often X's assignments are kept") |
The ICS feed is user-provided, opt-in and reduced to OOO intervals at import. Absence reasons (illness, parental leave) are special-category or sensitive data and must never be inferred or stored.
3. EU AI Act ​
Sources: Regulation (EU) 2024/1689 (EUR-Lex), as amended by Regulation (EU) 2026/1744 "Digital Omnibus on AI" (EUR-Lex).
3.1 Is the feature an "AI system" (Art. 3(1))? ​
- A weighted score with weights set by humans and fixed formulas (decay, counts) is close to the "basic data processing" and human-defined rules the Commission's guidelines on the AI system definition place outside Art. 3(1) (Commission guidelines, February 2025).
- Inferring familiarity from file-path similarity (RevFinder-style) and adjusting weights from reassignment outcomes is inference "from the input it receives" and adaptiveness, which point towards an AI system.
- Working assumption: treat the feature as an AI system. Counsel to confirm (open question Q1). If counsel concludes it is not an AI system without learning, keeping learning off would be a design lever.
3.2 Annex III point 4 ​
Annex III point 4(b) lists AI systems "intended to be used to make decisions affecting terms of work-related relationships, … to allocate tasks based on individual behaviour or personal traits or characteristics or to monitor and evaluate the performance and behaviour of persons in such relationships" (Annex III).
| Element | Analysis |
|---|---|
| Work-related relationship | Yes for company repositories (employees, contractors). Not for external open-source contributors without a work relationship with the deployer; Annex III point 4 then does not apply, GDPR still does. |
| Allocate tasks | Yes. Selecting reviewers and assignees is task allocation; in apply mode the system performs it, in suggest mode it prepares it. |
| Based on individual behaviour | Uncertain, likely yes. CODEOWNERS is an organisational designation, not behaviour, and workload/availability are state. Commit, blame and review history are records of a person's past work activity; a regulator can read them as "individual behaviour". |
| Personal traits or characteristics | No, by design (§2 exclusions). |
| Monitor and evaluate performance | Not intended. Risk: a per-person expertise score could be read as an evaluation. Mitigation: no per-person totals, no scores shown, no exports (ADR-0014). |
The Commission's draft classification guidelines (published 19 May 2026, consultation closed, final version not yet adopted as of October 2026) treat behaviour-based shift and workload allocation (punctuality, acceptance rates, responsiveness scores) as high-risk and say that human involvement alone does not change the classification; they give no example of purely skill- or ownership-based allocation (Commission draft; McCann FitzGerald summary).
3.3 Art. 6(3) derogation and its limits ​
Art. 6(3) allows an Annex III system not to be high-risk where it "does not pose a significant risk of harm … including by not materially influencing the outcome of decision making", if it performs a narrow procedural task, improves a completed human activity, detects patterns without replacing human assessment, or performs a preparatory task. Notwithstanding this, "an AI system referred to in Annex III shall always be considered to be high-risk where the AI system performs profiling of natural persons" (Art. 6).
- Candidate conditions: (d) preparatory task (suggest mode prepares the human allocation) and arguably (a) narrow procedural task.
applymode does not fit any condition: it makes the allocation. - Material influence: a ranked suggestion with reasons is designed to influence the choice; "not materially influencing" is hard to argue.
- Profiling limit: profiling is defined by Art. 4(4) GDPR as automated processing "to evaluate certain personal aspects relating to a natural person, in particular to analyse or predict aspects concerning that natural person's performance at work, … reliability, behaviour …" (GDPR). Inferring a person's familiarity with code from their activity history is plausibly such an evaluation. If it is profiling, the derogation is excluded.
- Procedure if relied upon: document the assessment before placing on the market and register under Art. 49(2) (Art. 6(4)). The Omnibus keeps registration but says it should be simplified (Reg. 2026/1744, recital 22); the details of the simplified Annex VIII content should be confirmed by counsel.
Preliminary view: the derogation is unlikely to be available, mainly because of the profiling limit. Plan for the high-risk case unless counsel concludes the feature is outside Annex III point 4 (Q2, Q3).
3.4 Application dates (verified October 2026) ​
| Item | Status | Source |
|---|---|---|
| Digital Omnibus on AI | Confirmed: adopted as Regulation (EU) 2026/1744 (Parliament 16 June 2026, Council 29 June 2026), published in the OJ 24 July 2026, in force 27 July 2026 | EUR-Lex; Praxikon |
| Annex III high-risk obligations (Chapter III Sections 1–3) | Confirmed: apply from 2 December 2027 (amended Art. 113(b)(i)); the original 2 August 2026 date no longer applies. Fixed date, not conditional on standards | EUR-Lex; Commission timeline |
| Annex I (product-embedded) high-risk | Confirmed: 2 August 2028 | same |
| Art. 50 transparency | Confirmed: applies since 2 August 2026 | Commission timeline |
| Art. 4 AI literacy | Applies since 2 February 2025; the Omnibus softened it to a duty to support AI literacy (confirm final wording) | Gibson Dunn |
| Classification guidelines (Art. 6(5)) | Draft only (19 May 2026); final expected by end of 2026 | Commission draft |
| Harmonised standards for high-risk requirements | Not yet available as of this draft (counsel to confirm) | — |
3.5 Roles ​
| Edition | Provider (Art. 3(3)) | Deployer (Art. 3(4)) | GDPR roles |
|---|---|---|---|
| Self-Hosted | Quavon UG (haftungsbeschränkt), as the party placing the system on the market under its name, also when distributed under Apache-2.0: the open-source exclusion of Art. 2(12) does not cover high-risk systems (Art. 2) | The customer (employer) operating it | Customer is controller; Quavon UG (haftungsbeschränkt) has no access to personal data |
| Enterprise (Quavon-hosted) | Quavon UG (haftungsbeschränkt) | The customer (employer) | Customer is controller; Quavon UG (haftungsbeschränkt) is processor (Art. 28 GDPR) |
- A customer who changes the intended purpose or substantially modifies the system (e.g. forks the code and adds performance inputs) can become a provider under Art. 25(1) (Art. 25). The instructions for use must state the prohibited uses and the excluded inputs.
- Quavon as provider must not use tenant data for its own purposes; per-tenant learning only.
3.6 Obligations if high-risk ​
| Party | Obligations (Regulation (EU) 2024/1689) | Applies from |
|---|---|---|
| Provider (Quavon) | Risk management (Art. 9); data and data governance (Art. 10); technical documentation, Annex IV (Art. 11); automatic logging (Art. 12); transparency and instructions for use (Art. 13); human oversight design (Art. 14); accuracy, robustness, cybersecurity (Art. 15); quality management system (Art. 17); conformity assessment by internal control, Annex VI (Art. 43(2)); EU declaration of conformity and CE marking (Arts. 47, 48); registration in the EU database (Art. 49(1)); post-market monitoring and serious-incident reporting (Arts. 72, 73) | 2 December 2027 |
| Deployer (customer) | Use per instructions, competent human oversight, input data relevance, monitoring, log retention at least six months, and — as employer — inform workers' representatives and affected workers before putting the system into service (Art. 26(1), (2), (4), (5), (6), (7)) (Art. 26); explanation on request for decisions with significant effects (Art. 86) (Art. 86). A fundamental-rights impact assessment (Art. 27) is not expected for private employers (counsel to confirm) | 2 December 2027 |
Until then: Art. 4 (AI literacy) and Art. 50 (transparency of AI output, e.g. labelled explanation comments) already apply.
4. GDPR and German employee data law ​
| Topic | Analysis | Source |
|---|---|---|
| Legal basis | Employees: Art. 88 GDPR with § 26(1) BDSG, or a works agreement (§ 26(4) BDSG, which must meet Art. 88(2)). After CJEU C-34/21, § 26(1) sentence 1 BDSG is widely considered not to meet Art. 88(2); controllers should rely on Art. 6(1)(b) (performance of the employment contract: organising work) and/or Art. 6(1)(f) (legitimate interest: efficient, knowledge-spreading review), with a documented balancing test. Non-employees (OSS contributors, contractors): Art. 6(1)(f). A German employee data act (BeschDG) was still in draft as of 2026 | CJEU C-34/21; § 26 BDSG; BeschDG status |
| Art. 21 objection | Where Art. 6(1)(f) is used, individuals can object; the individual opt-out implements this without requiring a reason | GDPR Art. 21 |
| Art. 22 automated decisions | suggest: a human decides, but CJEU C-634/21 (SCHUFA) holds that an automated score can itself be a "decision" where it plays a "determining role". apply: the allocation is automated. Whether a review or issue assignment "similarly significantly affects" a person is doubtful for single assignments but uncertain for systematic allocation. Mitigations: humans override at any time, explanation, opt-out, no use for HR decisions | CJEU C-634/21 |
| Art. 13/14 transparency | Data comes partly from third parties (GitHub, git history): Art. 14 information through the transparency page and the deployer's employee privacy notice (template text to be provided) | GDPR Arts. 13, 14 |
| DPIA (Art. 35) | Likely required. Meets several EDPB/WP29 criteria (evaluation/scoring, systematic monitoring, vulnerable data subjects — employees, innovative technology) and the German DSK list (No. 8: extensive processing of employee behaviour data that can be used to assess their work; No. 11: AI to evaluate personal aspects). Deployer conducts it; Quavon provides a DPIA template | WP248 rev.01; DSK Muss-Liste |
| Minimisation (Art. 5(1)(c)) | §2 exclusions; per-path cache instead of person profiles; availability from/to only; no historical workload | ADR-0014 |
| Retention (Art. 5(1)(e)) | Proposal in ADR-0014: assignment records and explanations 6 months (equals the Art. 26(6) minimum if high-risk); availability intervals deleted 30 days after the end; familiarity cache derived and recomputed, not historised; applied-assignment audit entries follow the audit-log policy | ADR-0014, ADR-0008 |
| Data subject rights | Export and deletion per person via DSAR tooling including assignments, availability, feedback | data-subject-rights.md |
5. Works Constitution Act (BetrVG) ​
| Provision | Analysis | Source |
|---|---|---|
| § 87(1) No. 6 | Co-determination for introducing and using technical equipment that is objectively suitable to monitor employees' behaviour or performance; the employer's intent is irrelevant (BAG 9 September 1975, 1 ABR 20/74). Data entered or produced by others and then processed by the system suffices (BAG 14 September 1984, 1 ABR 23/82). The BAG applied this to a Facebook page where third parties can comment on employees (13 December 2016, 1 ABR 7/15) and reaffirmed that intent does not matter for Microsoft Office 365 (8 March 2022, 1 ABR 20/21, para. 30; that decision also allocates competence to the group/central works council for enterprise-wide tools). Quavon processes per-person commit, review and assignment data on company systems, so the feature is very likely objectively suitable, regardless of mode or team-only settings. Contrast: ArbG Hamburg 16 January 2024, 24 BVGa 1/24 (no co-determination for ChatGPT used via private accounts; no data reached the employer) — not transferable here | BAG 1 ABR 20/74; BAG 1 ABR 7/15; BAG 1 ABR 20/21; ArbG Hamburg (Gleiss Lutz); § 87 BetrVG |
| § 90(1) No. 3, § 90(2) | Employer must inform the works council in good time about planning of work procedures "einschließlich des Einsatzes von Künstlicher Intelligenz" and consult on the effects on employees | § 90 BetrVG |
| § 80(2), (3) | Information rights; where the works council must assess the introduction or use of AI, an expert is deemed necessary (§ 80(3) sentence 2), at the employer's cost | § 80 BetrVG |
| § 87(1) No. 1 (possibly) | Rules on conduct in the establishment, if the employer mandates use of the suggestions | counsel to assess |
Consequence: for German tenants with a works council, even suggest mode must not be activated before co-determination is completed (works agreement or agreement in the conciliation committee). Individual consent or opt-in does not replace co-determination.
6. Risks and design mitigations ​
| # | Risk | Legal hook | Mitigation (ADR-0014) |
|---|---|---|---|
| R1 | Feature is high-risk and obligations are not met by 2 December 2027 | AI Act Arts. 6, 16, 26, 113 | Recommend-only default; apply behind instance legal sign-off; high-risk documentation (risk management, logging, instructions for use, human oversight) prepared with the feature so a conformity assessment is feasible |
| R2 | Suggestions read as performance evaluation | Annex III 4(b), Art. 4(4) GDPR, § 87(1) No. 6 | No per-person scores shown or exported; explanation facts limited to code-artefact facts; no rankings of other candidates shown publicly |
| R3 | Inputs drift towards behaviour or performance signals | Annex III 4(b), Art. 5(1)(c) GDPR | Closed input allowlist in code and tests; any new factor requires an ADR amendment and renewed legal review |
| R4 | Automated allocation without effective human control | Art. 22 GDPR, Art. 14 AI Act | Humans can change every assignment; apply opt-in per repo; reassignment never penalised |
| R5 | Learning creates per-person profiles | Art. 4(4) GDPR | Learning adjusts only per-repository factor weights, never per-person parameters |
| R6 | Monitoring through dashboards and analytics | § 87(1) No. 6, Art. 88 GDPR | Team-level-metrics-only switch; k ≥ 5 aggregation; per-person views only with tenant enablement and personal opt-in, and never in works-council mode |
| R7 | Sensitive data via calendars | Arts. 5, 9 GDPR | ICS reduced to OOO from/to at import; no titles, attendees, reasons |
| R8 | Individuals cannot object | Art. 21 GDPR | Individual opt-out: never auto-picked, still assignable manually |
| R9 | Lack of transparency | Arts. 13/14 GDPR, Art. 26(7) AI Act, § 90 BetrVG | Transparency page; labelled explanation comment; works-agreement template; information text for employees |
| R10 | Uncontrolled retention | Art. 5(1)(e) GDPR | Retention jobs per ADR-0014; DSAR export/delete |
| R11 | Introduction in Germany without co-determination | § 87(1) No. 6 BetrVG | Works-council mode on by default for German tenants; feature activation requires a recorded attestation |
| R12 | Customer repurposes the system (HR decisions, appraisal) | Art. 25 AI Act | Prohibited uses in instructions for use and terms; no export of per-person data; audit of configuration changes |
7. Decision table: acceptable modes per classification outcome ​
| Classification outcome (counsel) | off | suggest | apply | German tenants with a works council |
|---|---|---|---|---|
| A. Not an AI system, or not Annex III point 4 | ✓ | ✓ | ✓ after instance legal sign-off and per-repo opt-in | suggest only after works agreement; apply only if the works agreement explicitly allows it |
| B. Annex III point 4, Art. 6(3) derogation available (documented, registered) | ✓ | ✓ with documented assessment and Art. 49(2) registration | ✗ (automated allocation is not a preparatory task) | suggest only after works agreement |
| C. High-risk, before 2 December 2027 | ✓ | ✓ with high-risk documentation in preparation, deployer informed of upcoming duties | ✗ | suggest only after works agreement |
| C. High-risk, from 2 December 2027, conformity not completed | ✓ | ✗ for work-related relationships (public OSS repositories without work relationship: counsel to confirm) | ✗ | ✗ |
| C. High-risk, conformity assessment completed, registered, CE-marked | ✓ | ✓ | Only if counsel confirms that automated allocation is acceptable under Art. 22 GDPR and Art. 14 AI Act | suggest after works agreement; apply only if counsel and works agreement allow |
| Undecided (no sign-off recorded) | ✓ | Internal evaluation only (shadow, dashboard visible to instance admins, no comments) | ✗ | ✗ |
8. Open questions for counsel ​
- Q1 AI system: is a weighted, human-configured scoring with file-path similarity an AI system under Art. 3(1)? Does per-repository weight learning change the answer?
- Q2 Annex III scope: are commit, blame and review history on affected files "individual behaviour" for Annex III point 4(b), or code-artefact relationships outside it? Does ownership via CODEOWNERS alone fall outside?
- Q3 Profiling: is per-path familiarity derived from activity history profiling under Art. 4(4) GDPR, excluding the Art. 6(3) derogation? Does avoiding per-person aggregates change this?
- Q4 Recommend-only: can
suggestmode qualify as a preparatory task under Art. 6(3)(d) given the profiling limit and the draft guidelines' statement that human involvement alone does not change classification? - Q5 Roles: confirm Quavon is provider for the self-hosted Apache-2.0 edition and the hosted edition; when does a customer modification make the customer a provider (Art. 25)?
- Q6 Art. 22 GDPR: does a systematic review or issue assignment "similarly significantly affect" employees? Is
applyacceptable with override and explanation? Effect of SCHUFA onsuggest? - Q7 Legal basis: Art. 6(1)(b) vs (f) for employees after C-34/21; balancing test content; status of the German BeschDG.
- Q8 DPIA: confirm a DPIA is required; who provides which parts (Quavon template, deployer assessment)?
- Q9 Retention: is 6 months for assignment records proportionate; should it be shorter outside the high-risk case?
- Q10 BetrVG: is the system objectively suitable for monitoring even in team-only mode with no per-person views? Which body is competent for multi-site tenants (BAG 1 ABR 20/21)? Should
applyever be offered to German tenants? - Q11 Other jurisdictions: works-council mode for Austria (ArbVG § 96, § 96a) and other EU countries with co-determination; how to treat tenants with mixed workforces.
- Q12 Open-source repositories: for public repositories with external contributors (no work relationship), is Annex III point 4 out of scope while employees in the same repository are in scope?
- Q13 Art. 50: does the explanation comment need AI labelling under Art. 50, or is it covered by the existing "automated" notice?
- Q14 Registration: content and timing of Art. 49 registration (full or simplified per Omnibus recital 22) if relied on Art. 6(3) or if high-risk.
9. Sign-off ​
The feature is used beyond internal evaluation (shadow mode) only after the rows below are completed and the instance legal sign-off flag (ADR-0014) references this document version.
| Role | Name | Organisation | Date | Outcome (classification A/B/C, permitted modes) | Signature |
|---|---|---|---|---|---|
| External counsel (AI Act, GDPR) | |||||
| Counsel (German labour law) | |||||
| Data protection officer | |||||
| Works council (per German deployment) | |||||
| Provider product owner | Quavon UG (haftungsbeschränkt) |