Governance, evidence and handover

At Level 5 Operator, an AI system is a continuing organisational responsibility: purpose, people, data, suppliers, controls, evidence, cost, fallback, and a decision about whether it should operate. The operator must show the current position without the builder's memory.

2. Four answers and no document

An auditor, funder, customer, ethics body, or regulator asks: “Which AI systems does this team operate?”

The Lab lead lists the literature pipeline. A researcher adds the self-hosted assistant. The administrator remembers a sample tracker that generates anomaly notes. The departing builder says the tracker is “only a prototype,” although three people use its output every week. Nobody can state, from one current record, what each system is for, what data it touches, who owns its risks, who has been trained, which evidence is retained, or what happens when the builder leaves.

The Company version is the same failure in different clothing. The service manager lists the inbox triage workflow; IT lists the department assistant; Finance lists a reporting helper. Procurement has a fourth vendor entry. Security's spreadsheet calls one system retired, while its service identity made a request yesterday.

Build one operational AI inventory. Each row points to evidence, a decision, and a handover route. A substitute uses it while the author stays silent. Every row also asks whether the activity should be automated.

3. After this you can

• Keep an accountable inventory of what AI is doing in one company department or research group, including unofficial and paused systems, with practical risk tiers and separate applicability decisions.
• Produce proportionate evidence an auditor or regulator is likely to ask for, including role-specific AI literacy and tested retention, without storing sensitive payloads by default.
• Hand over operations through a one-page architecture, credential inventory, runbooks, fallback, and an “author has left” test.
• Decide not to automate when irreversibility, human-contact needs, legal exposure, or a poor fallback makes the proposed use indefensible.

4. Prerequisites

• T12-L04 - Put a lock on it: securing a self-hosted stack, including the dated external audit, administrator review, logging boundary, and tested restore.
• T03-L05 - Regression sets and evaluation ops, including versioned evaluation evidence, release gates, monitoring, and substitute-operation rehearsal.
• Written authority from the Lab group lead or Company department owner to discover systems and inspect approved metadata, contracts, training records, audit controls, and runbooks.
• A named inventory owner, one accountable owner per system, relevant privacy/security/legal/research-ethics contacts, and a substitute operator who did not build the systems.
• An approved restricted workspace for the inventory and evidence references.

Use public, synthetic, course-provided, or explicitly approved data. The systems, people, records, event IDs, costs, and findings below are fictional. Do not paste prompts, participant or customer records, unpublished results, personnel decisions, credentials, API keys, contracts, raw logs, model outputs, or investigation material into the exercise. Record protected evidence by controlled reference, owner, date, and access class.

This lesson is an operating method, not a legal classification or compliance certificate. Laws, guidance, enforcement dates, local employment rules, research obligations, contracts, and organisational policies change. Record the source and checked date for every applicability decision, and send uncertain or consequential cases to the authorised specialist. Never use a course page or a model answer as the final legal decision.

5. The idea in one page

Inventory systems by effect, not by product name

Inventory a use when software performs or materially supports an AI-mediated task, even if it is called a feature, copilot, classifier, experiment, plugin, or temporary script. Include systems that are proposed, piloting, active, paused, being retired, or recently retired. Include purchased services, hosted APIs, self-hosted models, embedded vendor features, and unattended workflows. Do not create one row per model when several models are interchangeable components of one governed purpose; do create separate rows when purposes, affected people, data, owners, or control boundaries differ.

Each row must name the bounded purpose and lifecycle; accountable owner and substitute; affected people; input and output data classes; locations, recipients, suppliers, tools, and actions; internal tier and separate applicability assessment; control evidence; and the stop, fallback, recovery, handover, and review paths. “The team” is not an accountable owner.

Use an operating tier, not a homemade legal verdict

The following one-page tier is a triage tool. It decides operating scrutiny; it does not declare a use compliant or assign a legal category under the EU AI Act or another regime.

Assign the highest tier triggered by purpose, affected people, data, action, scale, or failure consequence. Do not lower a tier because a model runs locally, a supplier calls it low risk, or a person can theoretically override an output. Record both inherent tier before controls and residual decision after tested controls. A Tier 3 system does not become Tier 1 because safeguards exist.

Keep legal applicability in a separate field: assessment required / assessment reference / decision owner / source version or URL / checked date / next trigger. The EU AI Act's Article 4 AI-literacy duty applied from 2 February 2025. The Commission's current Q&A says the July 2026 amendment retained an obligation for providers and deployers to take measures supporting AI-literacy development, while no specific or “sufficient” level is mandated. Context and people's knowledge, experience, education, and training still matter. Check the current consolidated law, official guidance, and competent advice rather than copying a stale chart.

Evidence is a chain, not a folder of screenshots

For each claim, identify the decision, observed test, revision, time, actor role, result, and protected evidence reference. A configuration screenshot proves only what one screen displayed. It does not prove effective access, deletion, output quality, or recovery.

A useful evidence chain connects:

inventory row and purpose revision
  -> authority and risk/applicability decision
  -> data and supplier boundary
  -> trained roles and competence check
  -> release/evaluation record
  -> access, limit, logging, fallback, and restore tests
  -> monitored events, incidents, changes, and review decision

Keep evidence proportionate. Operational trails usually need stable event or trace ID, time, system and release revision, actor or workload identity, action category, policy decision, result, usage, and evidence class. Raw prompts, retrieved text, outputs, personal details, tokens, and secrets are not default audit fields. Decide retention by purpose, obligation, incident need, sensitivity, access, storage location, deletion method, and owner. “Keep forever in case of audit” is not a retention policy.

Literacy means role-specific capability

Under the current amended Article 4 described by the Commission, providers and deployers in scope must take measures supporting AI-literacy development among staff and other persons dealing with AI systems on their behalf; no specific level is mandated. The inventory turns that duty into an operating question: what must each role understand to perform this use safely?

Record role, required capability, learning measure, practical check, completion or observation date, assessor or evidence owner, gaps, and refresher trigger. A Lab reviewer may need to detect unsupported scientific claims and preserve correction notices. A Company triage reviewer may need to recognise a requested access change, reject prompt-like instructions in source text, and escalate a misroute. An operator additionally needs stop, rollback, incident, retention, and supplier-change procedures. A generic awareness video can be one measure; attendance alone does not show that a person can perform the relevant control.

Ownership ends only after handover works

For every Tier 2 or Tier 3 row, link five handover elements:

• a one-page architecture showing users, ingress, model route, data stores, tools, logs, identity, suppliers, and trust boundaries;
• a credential and access inventory containing identities, owners, scopes, storage references, rotation or expiry, and revocation controls, never secret values;
• normal-operation, release, stop, incident, restore, deletion, and retirement runbooks;
• monitoring, cost limits, service objectives, fallback, and known residual risks;
• a dated “author has left” result in which a substitute completes a bounded operation, diagnoses one synthetic failure, invokes the stop path, and locates recovery without private help.

Documentation only its author can interpret is not a handover. The substitute must know when not to restart.

6. The worked example: one team, three continuing systems

The running project contains the systems developed across this track: the bounded unattended pipeline from T12-L03, the secured shared assistant from T12-L04, and a small tracker used to review work. The Lab framing operates them for a fictional research group. The Company framing operates equivalent systems for a fictional service department. The controls are parallel; purposes and affected people remain distinct.

Start with discovery, including awkward answers

The inventory owner searches approved sources: service catalogue, SSO applications, gateway routes, secret-manager metadata, cloud and self-hosted accounts, automation schedules, procurement records, expense categories, browser-extension approvals, repositories, model traffic summaries, privacy and ethics records, and interviews with process owners. Search metadata; do not open payloads merely to decide whether a system exists.

Ask which drafts, classifications, recommendations, or decisions the team relies on; which jobs call a model or embed an AI feature; which paused trials retain data or credentials; and which service would fail without its builder. These questions find more than “Do you use AI?”

The Lab finds a literature pipeline, a group assistant, and a sample-review tracker. The Company finds an inbox triage pipeline, a department assistant, and a service-issue tracker. A fourth personal transcription tool is discovered in each framing. It has no approved data route or owner, so it is recorded as discovered / blocked, access is contained through the authorised process, and potentially affected data is handled through incident or privacy review. Never omit shadow use to make the inventory look clean.

Create the common system register

Use one row per governed purpose. The compact view below is a synthetic illustration; the final inventory links the detailed evidence fields that follow.

Do not combine the Lab and Company into one real inventory. Choose the authorised framing; risk decisions depend on its actual context.

Complete one row deeply enough to operate

For AI-01, the Lab purpose is: read at most 25 records from one approved public literature fixture and create review-only metadata rows; never cite, publish, infer a missing result, or open participant or collaborator data. The Company purpose is: read at most 20 items from one approved synthetic inbox fixture and create review-only category drafts; never reply, refund, change access, move a message, or contact a person.

The detailed row records:

System ID / name / inventory revision: AI-01 / bounded review pipeline / inv-r3
Lifecycle: active; first approved date; last material change; retirement trigger
Purpose / affected workflow / affected people: [bounded statement]
Accountable owner / operator / reviewer / substitute: [approved roles]

Components: workflow revision; exact model route or local model revision; parser;
  source and review-only destination; identity; logging and alert service
Data: field-level input/output classes; source; location/region; recipients;
  prohibited data; prompt/retrieval/log/cache/backup handling
Suppliers and terms: provider; role; approved use; change-notice owner; assessment refs
Actions and limits: read/create only; human review; volume, retry, time, usage, cost;
  kill switch; forbidden actions

Inherent tier / rationale: Tier 2 / shared unattended drafting can spread error
Applicability assessment: required status; decision ref; owner; official source;
  checked date; recheck trigger
Residual decision: approved within listed boundary | blocked | retiring

Evidence references: authority; data review; security audit; regression gate;
  access/limit/stop tests; monitoring; cost; incident; restore; deletion
Literacy record by role: capability; measure; practical check; date; gap; refresh trigger
Audit trail: event classes and fields; readers; retention; deletion test; evidence owner

Architecture / credential inventory / runbooks: controlled references and revisions
Fallback / recovery objective / stop and restart authority: [observed controls]
Author-has-left test: scenario; substitute; result; gaps; date; evidence ref
Review: next date plus change, incident, supplier, law, data, scale, and owner triggers

Unknown values are findings, not blank cells. Secret-store paths may also be sensitive; use approved references. A public submission contains synthetic replacements, not internal topology.

Link evidence that answers a real question

For each active row, build an evidence index inside the same inventory. References point to controlled records rather than duplicating them:

Cost is also operational evidence. Record meter and rate source, attribution key, budget period, warning and stop thresholds, owner, and fallback. State pricing and date assumptions; include self-hosted capacity and infrastructure rather than calling it free.

Record literacy by role and test it

For the Lab pipeline, give a reviewer a normal record, an unreported sample size, a correction notice, and a title containing a hostile instruction. For the Company, use an ordinary request, an access-change request, an ambiguous message, and a quoted exfiltration instruction. Pass requires preserving missing information, surfacing escalation signals, treating hostile phrases as content, taking no consequential action, and keeping output in review. The operator must also locate the limit, stop new work, identify the evidence event, and name escalation.

Record results by role, not flattering comments:

Role: pipeline reviewer
Required capability: verify source-to-draft fields; recognise missing information,
  consequential requests, correction or escalation markers, and hostile content
Measure: walkthrough of purpose, prohibited actions, fallback, and reporting route
Practical check: LIT-CHECK-03 or INBOX-CHECK-03, synthetic fixtures only
Observed result/date: 3/4 passed; hostile-content escalation missed / 2026-09-04
Decision: not assigned independent review until coached retest passes
Owner / retest / refresh trigger: evidence owner / 2026-09-11 /
  workflow, model, data, policy, incident, or annual review change

An honest failed check is useful evidence. Training records should not expose unnecessary personal information; retain the approved role or identity reference, capability, result, and dates with restricted access and an appropriate retention basis.

Set and test retention with synthetic events

Classify evidence before choosing a period. Inventory decision history may need to outlive a short-lived debug trace. A security incident hold may suspend ordinary deletion for specifically governed records. These are different purposes and must not silently share forever.

Create a retention schedule inside the inventory. Separate durable inventory decisions from short-lived operational events and quality samples. Keep operational metadata without raw content by default; delete or minimise quality samples after review. Keep public or synthetic regression fixtures only while their requirements remain relevant. Keep minimum role, capability, result, and date fields for training evidence under the approved organisational schedule. Name readers and an owner for every class.

Use a test retention class or an approved synthetic event such as RETENTION-CANARY-004. Retrieve it before expiry, execute or await the documented deletion control, then search by exact event ID after completion. Record control revision, completion time, search result, and owner. If the real period cannot elapse during the exercise, mark deletion pending with the future verification date; do not call a configured lifecycle rule observed deletion.

Run the “author has left” test

The original builder becomes unavailable for the drill and may only observe. Give the substitute the inventory and normal approved access. Use synthetic data and a non-production or safely bounded operational window.

The substitute identifies AI-01's purpose, revision, owner, boundary, tier, and release decision; runs and traces one allowed synthetic item; diagnoses a bounded malformed item; stops new work; locates fallback, credential owners, and restore evidence without viewing secrets; and names restart authority. They then update the test result and gaps through the approved change process. Do not perform a disruptive production restore.

The Lab fallback is manual review of the public source and tracker with no automated citation. The Company fallback is manual triage in the approved queue with no generated response or account action. In both, the substitute must know that a failed quality gate, unknown data route, broken audit trail, expired approval, or failed stop control means remain stopped, not restart and monitor.

Suppose the substitute can stop the workflow but cannot rotate its model credential because the reference points to the builder's personal vault. The test fails. Transfer the credential to an organisation-controlled secret store through the incident/change process, revoke the personal path, update the credential inventory, test the synthetic replacement and revocation, and repeat the exact handover step. Do not copy a token into the inventory as a shortcut.

Decide whether each use should exist

Before approving or renewing a row, ask four final questions:

Reversibility: What can happen before a qualified person can detect and reverse it? A generated private draft is more reversible than a sent message, denied benefit, changed access right, published claim, or treatment recommendation.

Human contact: Is listening, explaining, negotiating, comforting, contesting, or taking responsibility part of the service itself? If so, replacing the conversation with automation can be the failure even when text quality is high.

Legal and ethical exposure: Could the use affect rights, safety, employment, education, credit, healthcare, research participants, authorship, or access to an essential service? Is there a current authorised assessment and meaningful route to challenge the outcome? If uncertain, block rather than improvise a classification.

Fallback quality: When the model, supplier, network, evidence store, or reviewer is unavailable, can the team deliver an acceptable service safely? A fallback that is unstaffed, undocumented, slower than the harm window, or dependent on the same failed supplier is not a fallback.

AI-04 remains Tier 0 because no owner can establish an approved data route and the meeting context may require confidential human exchange. The decision is not “AI is bad.” It is “this use lacks authority, boundaries, and an acceptable alternative to human handling.” The inventory records a blocked decision, responsible owner for containment, affected-data review reference, and re-evaluation condition.

7. What goes wrong

The inventory is written once

Symptom: rows still say pilot after regular use, retired services keep active credentials, and supplier or model changes do not alter the review date.

Fix: assign one inventory owner and row owners. Trigger review on purpose, data, model, supplier, tool, scale, ownership, law, incident, or control change, plus a fixed periodic check. Compare gateway, identity, procurement, scheduler, and service metadata with the register.

There is no owner per system

Symptom: AI team appears in every owner cell, but nobody can accept residual risk, fund controls, pause service, or decide retirement.

Fix: name an accountable role or approved identity and a substitute. If nobody accepts the purpose and consequences, block the system.

Internal tier is presented as legal classification

Symptom: a green spreadsheet cell is treated as proof that the use is outside regulation.

Fix: keep internal operating tier and legal/applicability assessment separate. Reference current official sources, authorised advice, decision owner, checked date, and recheck triggers.

Training leaves no useful evidence

Symptom: everyone watched the same awareness video, yet reviewers cannot recognise the use's critical failure or find its stop path.

Fix: map capability to role, provide context-specific measures, run a synthetic practical check, record result and gaps, and refresh after material change or incident.

Evidence is excessive but inconclusive

Symptom: raw prompts, documents, outputs, secrets, and personal details remain searchable indefinitely “for compliance,” while screenshots show an enabled limit and backup job that nobody has crossed or restored. The team has collected too much sensitive material without proving that its controls operate.

Fix: begin with the questions the trail must answer, minimise fields at collection, restrict readers, separate evidence classes, approve periods, and observe synthetic deletion. Apply legal hold only through the authorised process. For control claims, reference observed synthetic tests with revisions, dates, results, and owners; keep a failed or pending test visible.

The system belongs to its builder

Symptom: architecture lives in their head, credentials in their account, and every runbook ends with “ask Alex.”

Fix: move identities and records under organisational control, name substitutes, and repeat the author-has-left drill until no private instruction is needed.

A human is decorative

Symptom: one overloaded reviewer clicks approve after the system has already changed a consequential record.

Fix: move the gate before action, show source and consequence, provide authority and time to disagree, measure review quality, and remove automation when meaningful review cannot be sustained.

A conversation is automated because it is expensive

Symptom: a system handles complaints, distress, dismissal, consent, or contested decisions because human contact costs more.

Fix: treat human contact as a service requirement. Keep administrative assistance bounded, preserve a reachable human route, and record no automation when empathy, explanation, negotiation, or accountability is intrinsic.

8. Do it yourself: build one team's inventory in 90 minutes

Create one inventory artifact throughout this exercise. Use an approved real team scope, but use only metadata and public, synthetic, or explicitly approved content for active tests.

Minutes 0-10: name the team boundary, inventory owner, row owners, substitute, evidence workspace, discovery sources, and stop/escalation contacts. Record the official sources and date used for applicability review.

Minutes 10-22: search approved service, identity, gateway, scheduler, procurement, repository, secret-metadata, and interview sources. Include proposed, pilot, active, paused, retiring, retired-with-residue, embedded, and shadow uses. Do not inspect payloads to discover services.

Minutes 22-35: create one row per purpose. Record lifecycle, bounded purpose, affected people, components, owners, input/output data classes and locations, suppliers, actions, limits, prohibited uses, costs, and fallback. Unknown values become findings.

Minutes 35-45: assign inherent operating tiers using consequence, scale, reversibility, human contact, and fallback. Separately record applicability-assessment status, source, checked date, decision owner, reference, and recheck trigger. Block any use without authority or a tolerable fallback.

Minutes 45-58: add evidence references for authority, data handling, security, access, regression, release, limits, monitoring, costs, incidents, restore, retention, deletion, and review. Record revision, date, result, owner, and gap; never attach raw protected evidence to the submitted inventory.

Minutes 58-68: map roles to required AI literacy. Run one bounded synthetic practical check for a reviewer and one for an operator. Record observed results, gaps, assignment decision, retest date, and refresh trigger.

Minutes 68-76: define evidence classes, required fields, excluded content, readers, storage, periods, deletion controls, and owners. Retrieve and delete one approved synthetic canary, or mark future deletion verification honestly pending.

Minutes 76-86: select one Tier 2 or Tier 3 row. The author stays silent while the substitute follows the architecture and runbooks, processes one synthetic item, diagnoses one injected safe failure, stops new work, locates fallback and recovery evidence, and states restart authority. Record every undocumented step as a failed handover finding.

Minutes 86-90: ask the four no-automation questions for every row. Set each decision to approved within boundary, blocked, paused, or retiring; add next review dates and event triggers. Remove temporary access and synthetic test data according to the exercise rule.

Stop if discovery reveals possible unapproved sensitive-data use, a consequential live action, an unknown service owner, public exposure, unsupported legal assumptions, or a credential controlled only by an unavailable person. Preserve minimum metadata and invoke the authorised process; do not continue probing to make the inventory complete.

9. Exit check

Deliver exactly one artifact: an AI inventory for one real team with a risk tier, named owner, data touched, and training record for every entry.

Use this minimum structure inside that single artifact:

TEAM AI INVENTORY
Inventory ID / revision / scope / owner / reviewer / checked date:
Discovery sources checked / gaps / next reconciliation date:
Tier method revision / official applicability sources and checked date:

For every system:
ID / name / lifecycle / bounded purpose / affected people
Accountable owner / operator / reviewer / substitute
Components, suppliers, model route, tools, source and destination
Input/output data classes, locations, recipients, prohibited data and uses
Actions, human gates, scale, limits, cost boundary, kill switch, fallback
Inherent internal tier and rationale / residual decision
Applicability-assessment status / owner / reference / checked date / trigger
Evidence index: authority, data, security, access, evaluation, release,
  limits, monitoring, cost, incident, restore, retention and deletion
Training record by role: capability, measure, practical result, date, gap, refresh
Architecture, credential inventory and runbook references
Author-has-left result / unresolved gaps / restart authority
Decision / next review date / event triggers / retirement and deletion state

Inventory findings and owners:
Blocked or no-automation decisions and reasons:
Reviewer decision: PASS | BLOCKED

It passes only when discovery covers approved technical and administrative sources; shadow and paused uses remain visible; every entry has a bounded purpose, lifecycle, accountable owner, substitute, data boundary, inherent tier, separate applicability status, evidence references, role-specific training record, fallback, and review trigger; at least one approved synthetic retention/deletion result is observed or honestly scheduled; and a substitute completes the author-has-left test for one operational row without private help.

The decision is BLOCKED if any active entry has no owner, unknown data or supplier route, unsupported legal classification, missing role capability evidence, failed critical evaluation, untested stop path, indefinite default retention, no credible fallback, builder-only credential, or an automation purpose that fails the reversibility, human-contact, legal-exposure, or fallback judgement. Supporting logs, screenshots, contracts, credentials, assessments, and runbooks remain controlled references. They are not extra submitted artifacts.

10. Rule to remember

If you cannot hand it over, you do not own it - it owns you.

11. Further reading & tools

• Taught: Private AI for your org: buy, build & govern - establishes purpose, ownership, data and supplier boundaries, pause criteria, evidence, and review.
• Taught: What AI costs: tokens, time and money - establishes measured usage, explicit rate assumptions, budget boundaries, and cost attribution.
• Taught: Evals & testing: prove your AI works - establishes versioned fixtures, observable acceptance criteria, release evidence, and regression practice.
• Catalogued: T12-L04 - Put a lock on it: securing a self-hosted stack - supplies the external audit, access, logging, egress, secret, and restore evidence linked from the inventory.
• Catalogued: T03-L05 - Regression sets and evaluation ops - supplies the release gate, monitoring loop, trace boundary, and substitute-operation practice.
• Taught: EUR-Lex record for Regulation (EU) 2024/1689 (opens in a new tab) - official legal record with access to the regulation and available consolidated versions; check amendments before relying on one provision.
• Taught: European Commission AI literacy questions and answers (opens in a new tab) - current Commission explanation of role- and context-sensitive measures and evidence expectations.
• Catalogued: EU AI Act official text (opens in a new tab) - authoritative regulation text, including definitions, prohibited practices, high-risk rules, governance, penalties, and application dates.
• Catalogued: European Commission AI Act overview (opens in a new tab) - current official implementation overview and links; recheck it when reviewing dates or guidance.
• Catalogued: NIST AI Risk Management Framework (opens in a new tab) - voluntary framework for governing, mapping, measuring, and managing AI risk.
• Catalogued: NIST AI RMF Playbook (opens in a new tab) - suggested actions for ownership, documentation, measurement, monitoring, and review.
• Catalogued: ISO/IEC 42001 overview (opens in a new tab) - primary standards-body overview of an AI management system; access to the full standard may require purchase.
• Catalogued: T02-L05 - Running the assistant for everyone - applies the inventory to SSO, revocation, machine identities, quotas, logs, and shared-service operations.
• Catalogued: T05-L05 - Operating automations - extends the same evidence and ownership discipline across an automation portfolio.
• Catalogued: T10-L05 - Operating data pipelines - extends governance into ongoing data-quality ownership and monitoring.
• Catalogued: Tools index - compare governance, evidence, inventory, and monitoring products only after required fields and decision rights are fixed.