# Artefact templates: disclosures, documentation, oversight, logging

Companion to `artefacts-records.md`, which holds the inventory entry and the classification record. Same rules: every generated artefact carries `<!-- DRAFT — not legally cleared -->` as its first line until sign-off is confirmed, and unknown values stay as `[[MISSING: …]]` in the artefact and in the report back to the user.

## 1. Art 50 user-facing disclosures

Substance and placement per `transparency-art50.md`. Publish in the language of the interface; the explanation around them stays in English.

**Chat or assistant, first turn — Art 50(1).** Persistent, not dismissible into invisibility:

```
You are chatting with an AI assistant, not a person.
It can be wrong. [[Ask for a human]] at any time.
```

Placement: in the message thread as the first element and in the composer header, present before the user's first input. Not in a tooltip, not behind a "learn more", not only in the terms.

**Voice channel, opening line — Art 50(1):**

```
This call is answered by an automated AI assistant.
Say "agent" at any time to reach a person.
```

Spoken before the first substantive exchange, in the language of the call.

**Agent acting on someone's behalf — Art 50(1), Guidelines C(2026) 5054 final point 31.** Discloses both artificial nature and principal:

```
I am an AI assistant acting on behalf of [[principal name]].
I can [[permitted actions]]. I cannot [[excluded actions]].
```

**Generated image, video or audio — Art 50(2), provider side.** Not user-facing text; a technical specification:

```yaml
marking:
  layer_1_metadata:
    applies_to: [image, video, audio, containerised text]
    field: [[metadata field carrying the AI-generated flag]]
    signed: true                # digitally signed, tamper-evident
    timestamped: true
    key_management: [[where signing keys live and who controls them]]
    standard_or_best_practice: [[MISSING: named standard]]
  layer_2_watermark:
    applies_to: [image, video, audio, free-form text > 200 tokens]
    method: [[model-level | post-hoc]]
    implementation: [[MISSING: library or service and version]]
  optional_fingerprint_or_log: [[none | describe — never sufficient alone]]
detection:
  mechanism: [[endpoint, tool or API through which markings can be checked]]
  audience: [[public | verified expert users for free-form text]]
  result_states: [[indicates whether based on metadata, watermark, forensic]]
  interoperability_route: [[industry-standard access method | public signpost |
                            consortium solution | other]]
  interoperability_due: 2027-02-02
out_of_scope_outputs:
  - [[source code and configuration — Guidelines point 68]]
  - [[UI labels, alt-text, image captions, short sequences]]
  - [[machine-to-machine output not perceived by humans]]
exceptions_relied_on:
  - [[assistive standard editing — Art 50(2), reasoning]]
  - [[no substantial alteration of input data or its semantics — reasoning]]
```

**Deepfake label, deployer side — Art 50(4) first subparagraph.** Visual, using the EU icon from Annex 1 of the Code of Practice or an equivalent:

- Main element: capitalised **AI**, letters of equal vertical dimension, proportions preserved on resize.
- Second layer, encouraged: `generated` or `modified`, and what was modified.
- Placement: embedded in the content or an equivalent overlay, top-right or another position free of intervening elements, visible long enough to be noticed, at the latest at first exposure.
- Accessibility: screen-reader detectable, sufficient contrast, alternative cue where the visual is unavailable.

Audio-only, spoken at the beginning of the deep fake:

```
The following audio was generated by artificial intelligence.
```

**Published text on matters of public interest — Art 50(4) second subparagraph.** Above the fold, before the body text:

```
This text was generated by an AI system and published without human
editorial review.
```

If the human-review exception is relied on instead, record the natural or legal person holding editorial responsibility in the classification record; do not publish an unsupported claim of editorial control.

**Emotion recognition or biometric categorisation — Art 50(3), deployer side.** Before exposure:

```
This [[space | service | session]] uses a system that [[recognises emotions |
categorises people by biometric data]] for the purpose of [[purpose]].
[[Link to the privacy information and to how to object.]]
```

Check Art 5(1)(f) and (g) first: in a workplace or education institution, emotion inference is prohibited outright unless for medical or safety reasons.

## 2. Deployer instructions-for-use summary

Condenses the provider's Art 13 instructions into what the deploying organisation must actually do. One per deployed high-risk system.

```markdown
<!-- DRAFT — not legally cleared -->
# Instructions for use — operational summary: [[system]]
Provider: [[name, contact, authorised representative]] · IFU version: [[…]] · Received: [[date]]

## Intended purpose, verbatim from the provider
[[quote]]

## What we may use it for, and what we may not
Permitted: [[…]]
Out of scope — using it this way would breach Art 26(1) and may make us the
provider under Art 25(1)(c): [[…]]

## Declared performance — Art 13(3)(b)(ii), Art 15(3)
Accuracy metric and value: [[…]] · Conditions affecting it: [[…]]
Robustness: [[…]] · Cybersecurity: [[…]]
Performance for specific persons or groups: [[…]]

## Known limitations and foreseeable misuse — Art 13(3)(b)(iii)
[[…]]

## Input data we control — Art 26(4)
[[what we supply, and how relevance and representativeness are assured]]

## Human oversight — Art 13(3)(d), Art 26(2)
Roles: [[…]] · Competence and training: [[…]] · Authority to stop: [[…]]
Stop mechanism: [[how, and how the system halts in a safe state]]

## Logs — Art 13(3)(f), Art 26(6)
What is recorded: [[…]] · Where: [[…]] · Retention: [[≥ 6 months, reconciled]]

## Monitoring and escalation — Art 26(5)
Routine monitoring: [[who, how often, against what]]
On risk under Art 79(1): suspend use, inform [[provider contact]] and
[[market surveillance authority]] without undue delay.
On a serious incident: inform the provider first, then importer or distributor
and the market surveillance authority. If the provider is unreachable, Art 73
applies mutatis mutandis: 15 days; 2 days for widespread infringement or serious
and irreversible disruption of critical infrastructure; 10 days where a person dies.

## Notices we owe
Workers and their representatives before workplace use — Art 26(7): [[done / due]]
Persons subject to decisions — Art 26(11): [[text and placement]]
Art 50 disclosures: [[…]]

## Assessments
DPIA using the Art 13 information — Art 26(9): [[…]]
FRIA — Art 27, if we are a public body, a private provider of public services,
or a deployer of Annex III 5(b) or (c): [[required / not required, reasoning]]

## Open items
- [[MISSING: …]]
```

## 3. Model card / technical documentation skeleton, aligned to Annex IV

Headings follow Annex IV so that the model card and the technical file are the same document, not two. Providers that are SMEs or SMCs may use the Commission's simplified form under Art 11(1) as amended — record which was used.

```markdown
<!-- DRAFT — not legally cleared -->
# Technical documentation — [[system]] · version [[…]] · [[date]]
Annex IV to Regulation (EU) 2024/1689. Simplified SME/SMC form used: [[yes/no]]

## 1. General description — Annex IV(1)
(a) Intended purpose; provider name; version and relation to previous versions
(b) Interaction with hardware or other software, including other AI systems
(c) Software and firmware versions; version update requirements
(d) Forms in which it is placed on the market: [[embedded | download | API]]
(e) Hardware it is intended to run on
(f) Photographs or illustrations, where a component of a product
(g)+(h) Deployer user interface; instructions for use

## 2. Elements and development process — Annex IV(2)
(a) Methods and steps, including use of pre-trained systems or third-party tools,
    and how they were used, integrated or modified
(b) Design specifications: general logic and algorithms; key design choices with
    rationale and assumptions, including as to the persons or groups the system is
    intended for; main classification choices; what it optimises for; relevance of
    parameters; expected output and output quality; trade-offs made to meet
    Chapter III Section 2
(c) System architecture; computational resources used to develop, train, test, validate
(d) Data: datasheets for training methodologies and techniques and for the training
    sets — general description, provenance, scope, main characteristics, how obtained
    and selected, labelling procedures, cleaning methodologies
(e) Assessment of the human oversight measures under Art 14, including technical
    measures to facilitate interpretation of outputs under Art 13(3)(d)
(f) Pre-determined changes and the technical solutions ensuring continuous compliance
(g) Validation and testing: procedures, data and its characteristics; metrics for
    accuracy, robustness and other requirements; potentially discriminatory impacts;
    **test logs and test reports, dated and signed by the responsible persons**
(h) Cybersecurity measures

## 3. Monitoring, functioning and control — Annex IV(3)
Capabilities and limitations in performance; degrees of accuracy for specific persons
or groups and overall expected accuracy; foreseeable unintended outcomes and sources
of risk to health, safety, fundamental rights and discrimination; human oversight
measures; input data specifications

## 4. Appropriateness of the performance metrics — Annex IV(4)
## 5. Risk management system under Art 9 — Annex IV(5)
## 6. Relevant changes through the lifecycle — Annex IV(6)
## 7. Harmonised standards applied, with OJ references; where none, the solutions adopted — Annex IV(7)
## 8. Copy of the EU declaration of conformity under Art 47 — Annex IV(8)
## 9. Post-market monitoring system under Art 72, including the plan — Annex IV(9)

## Open items
- [[MISSING: …]]
```

For a **GPAI model** rather than a system, use Annex XI instead: general description including tasks, acceptable use policies, release date and distribution methods, architecture and number of parameters, input and output modalities, licence; then design specifications and training process, data used for training with type, provenance and curation, **training compute in FLOP**, training time, and known or estimated energy consumption. Systemic-risk models add evaluation strategies and results, adversarial testing, and system architecture.

## 4. Human oversight design note

Written by the provider under Art 14, implemented by the deployer under Art 26(2). One note per high-risk system.

```markdown
<!-- DRAFT — not legally cleared -->
# Human oversight design — [[system]]
Art 14 (provider design duty) · Art 26(2) (deployer assignment duty)

## Oversight objective — Art 14(2)
Risks to health, safety or fundamental rights that oversight is meant to prevent or
minimise, under intended use and reasonably foreseeable misuse: [[…]]

## Allocation — Art 14(3)
Built into the system by the provider: [[…]]
Identified for the deployer to implement: [[…]]

## Capability requirements — Art 14(4)
(a) Understanding capacities and limitations; monitoring operation; detecting and
    addressing anomalies, dysfunctions and unexpected performance
    → surfaced by: [[dashboards, alerts, confidence display, drift monitors]]
(b) **Automation bias** countermeasure
    → [[e.g. no pre-selected recommendation; mandatory reason capture on acceptance;
       periodic blind-review sampling; display of disagreement rate]]
(c) Correct interpretation of the output
    → [[interpretation tools, explanations, worked examples, calibration guidance]]
(d) Decision not to use, or to disregard, override or reverse the output
    → [[override control, where it is, who may use it, what is logged]]
(e) **Intervene or interrupt through a stop button or similar procedure that allows
    the system to come to a halt in a safe state**
    → [[control, what "safe state" means here, expected latency, who is notified]]

## Two-person rule — Art 14(5)
Applies only to Annex III point 1(a) remote biometric identification: no action or
decision on the basis of an identification unless separately verified and confirmed by
at least two natural persons with the necessary competence, training and authority.
Applicable here: [[yes / no]]

## People — Art 26(2)
Roles: [[…]] · Named individuals or on-call rota: [[…]]
Competence: [[…]] · Training completed: [[date, content version]]
Authority: [[the decision they may take without escalation]]
Support: [[who they escalate to, and how fast]]

## Evidence
Every override, suspension and stop is logged with: timestamp, actor, system output,
action taken, reason. Retention: [[…]]

## Open items
- [[MISSING: …]]
```

## 5. Log retention specification

Reconciles three regimes that pull in different directions: the AI Act floor, GDPR storage limitation, and sectoral law.

```yaml
# <!-- DRAFT — not legally cleared -->
system: [[AIS-0001]]
role: [[provider | deployer]]

purpose_of_logging:              # Art 12(2)
  - identify situations that may cause a risk under Art 79(1) or a substantial modification
  - facilitate post-market monitoring under Art 72
  - enable deployer monitoring under Art 26(5)

events:
  - name: [[inference_request]]
    fields: [[timestamp, system version, model version, input reference,
              output reference, confidence, latency, actor]]
    personal_data: [[yes/no — categories]]
    retention: [[e.g. 6 months]]
    basis_for_period: [[Art 19 (provider) / Art 26(6) (deployer) floor of at least
                        six months, plus [[sectoral rule]], minus GDPR Art 5(1)(e)]]
  - name: [[human_override]]
    fields: [[timestamp, actor, original output, action, reason]]
    retention: [[…]]
  - name: [[incident]]
    fields: [[…]]
    retention: [[…]]

annex_iii_1a_minimum:            # Art 12(3) — remote biometric identification only
  applicable: [[yes/no]]
  fields_if_applicable:
    - period of each use: start date and time, end date and time
    - reference database checked against
    - input data for which the search led to a match
    - identification of the natural persons involved in verifying results (Art 14(5))

floors_and_ceilings:
  ai_act_floor: [[at least 6 months — Art 19 provider / Art 26(6) deployer]]
  gdpr_ceiling: [[storage limitation, Art 5(1)(e) — what forces a shorter period]]
  sectoral_override: [[e.g. financial services record-keeping — cite it]]
  conflict_resolution: [[what wins per field, and why]]

access:
  who_may_read: [[…]]
  logged_on_access: [[yes/no]]

deletion:
  mechanism: [[automatic job, verified]]
  verification: [[how deletion is proven]]

open_items:
  - [[MISSING: …]]
```


## Checkpoints

- [ ] Draft marker present as the first line of every generated artefact
- [ ] No placeholder silently filled with a plausible value
- [ ] Art 50 disclosures placed at or before first interaction or exposure, not behind a link
- [ ] Marking specification pairs every marking layer with a detection route
- [ ] Instructions-for-use summary quotes the provider's intended purpose verbatim
- [ ] Technical documentation follows the Annex IV headings, with dated and signed test reports
- [ ] GPAI model documentation follows Annex XI instead, with training compute in FLOP
- [ ] Oversight note names a real stop mechanism and a real automation-bias countermeasure
- [ ] Log spec reconciles the six-month floor against GDPR storage limitation field by field
- [ ] Open items repeated in the report back to the user