Documenting prompts, RAG sources, and guardrails in EU AI Act technical documentation

What the documentation obligation requires

For a high-risk AI system, the technical documentation must be drawn up before the system is placed on the market or put into service, and it must be kept up to date. Article 11(1) requires it to contain at least the information set out in Annex IV, as applicable to the system. SMEs, including start-ups, may provide the Annex IV elements in a simplified manner. The recitals describe the purpose: assessing compliance and supporting post-market monitoring.

The recitals also describe what the information should cover: the system's general characteristics, capabilities and limitations, the algorithms, data, and training, testing and validation processes used, and documentation of the relevant risk-management system, in a clear and comprehensive form. Prompts, retrieval sources and safety controls are not named in that framing. In an LLM-based system, though, they often determine the system's behavior more directly than any other component, so they belong in the documentation as concrete, inspectable artifacts. The mapping below is a practical interpretation. Confirm it against the full Annex IV text with legal counsel before adopting it.

Role matters. A provider of a high-risk system works under Article 11 and Annex IV. A provider of a general-purpose AI model has a separate duty to maintain model documentation containing at minimum the Annex XI information. A team building on a third-party model should establish which duties apply to it before deciding how deep its documentation needs to go.

The four artifacts and where they map

A repeatable structure starts with four artifacts. Each answers a question a reviewer is likely to ask, and each maps to a documentation theme in the Annex IV framing.

• Prompt inventory: Lists every system instruction, template and routing prompt in use, with version, owner, purpose, approval status and intended behavior. It supports the description of general characteristics, capabilities and limitations, because instructions define what the system is meant to do and refuse to do.
• Retrieval source register: Lists each RAG corpus or index with its business purpose, owner, refresh cadence, access constraints, licensing terms and the data categories it contains. It supports the description of the data the system relies on at inference time, which is distinct from training data.
• Policy and control specification: Defines each runtime control: what it detects, the action it takes (allow, redact, block, rate limit, escalate for human approval), its configuration and the risk it mitigates. It links the technical description to the documented risk-management system.
• Change history: Records each revision to the three artifacts above, with date, author, approver and reason. It is the mechanism that keeps documentation current over the system's lifetime.

Deciding what to document and when to revise

Document the prompts, corpora and control configurations that are active in the system as deployed, not every experiment. A useful test is whether a change could alter the system's behavior, its limitations or its risk profile. Production system instructions, corpora that feed answers to users, and any control that gates an action meet that test. Draft prompts in a development branch generally do not.

Because documentation must be kept up to date, define revision triggers in advance. Reasonable triggers include a new or materially edited production prompt, adding or removing a retrieval corpus, a change in a corpus's access or licensing terms, and a change to a control's configuration or action. The criteria are an organizational decision, so write them down and have the risk owner approve them. Minor edits such as typo fixes can be recorded in the change history without a documentation revision.

Assign one named owner per artifact. Prompt owners are typically product or engineering leads, retrieval source owners are data stewards, and control owners sit in security or risk. Compliance holds the structure and reviews it against the quality management system documentation, which sits alongside the technical documentation, so the two do not diverge. Ownership of keeping documentation aligned with post-market monitoring should be explicit, since the documentation is meant to support that monitoring.

Design-time documentation versus operational evidence

Documentation describes what the system is and what the controls are intended to do. It is written before deployment and revised at defined points. It cannot show that a control actually fired, was bypassed or was misconfigured last Tuesday.

Operational evidence is the record of what happened. The recitals state that high-risk systems should technically allow automatic recording of events over the lifetime of the system. A reviewer comparing the two should be able to take a control described in the specification and find records showing how it behaved in operation. A specification that says sensitive identifiers are redacted before reaching a model is a claim. Records of redaction decisions on real interactions are the evidence for it.

The tradeoff is that evidence only exists for controls that run in the execution path and record their decisions. Controls applied as periodic review or as advice in a prompt produce little that can be shown later. When selecting controls, ask what each one will leave behind, how long it is retained, and who can retrieve it on request.

Runtime policy enforcement as evidence, and its limits

Policy enforced in the execution path produces a decision record for each event it handles: the action taken (allow, redact, block, rate limit or escalate for human approval), the policy version applied and the time. Trussed enforces policy at runtime in this way across models, agents, tools and MCP servers, and generates audit-ready evidence from those decisions, mapped to the EU AI Act among other frameworks. Enforcement happens at runtime, not by review after the fact, so the evidence reflects what the control did rather than what was intended.

The scope is individual interactions and tool calls. That is useful for showing that a given control behaved as specified, but it has limits. Interaction-level and tool-call-level records do not describe model provenance, dataset provenance or an end-to-end trace of an agentic workflow. Those gaps need to be covered by other documentation or by other tooling. State them in the control specification so a reviewer sees the boundary of what the evidence supports.

Deployment choices also affect evidence. Trussed can be self-managed in the customer cloud, with configurable retention and data residency, which lets a regulated enterprise align evidence retention with its own obligations. Whatever tool is used, record the retention period and storage location in the control specification.