A.6.2.7 AI technical documentation: requirements and proof

A.6.2.7 AI system technical documentation: what it asks for

A.6.2.7 requires the organization to determine what AI system technical documentation each relevant category of interested parties needs, such as users, partners and supervisory authorities, and to provide that documentation in an appropriate form. The control is about fit, not volume: a rich architecture document that a customer support team cannot use does not satisfy it. The risk it addresses is familiar. Users and partners misuse a system whose limits were never written down, trust outputs in situations the model was not built for, or cannot tell which parts of the system are human-controlled. Supervisory authorities and customers then ask questions the organization cannot answer from its own records.

The control is hard in practice for two reasons. First, the material is scattered across tickets, notebooks, model cards, slide decks and chat threads, so no single source describes the system as it is today. Second, nobody owns keeping it current after launch, so documentation drifts away from the deployed model, data sources and known failure modes. Annex B guidance for this control ties the documentation to knowledge limits, human oversight and residual risk, which means a team should be able to show which risks remain after controls are applied and what users must do about them. Auditors will judge what the team can actually produce on request, including whether each audience's version is current, traceable to a release, and approved by a named owner.

Which AI systems, audiences and teams fall under A.6.2.7

Before writing any documentation, the organization has to settle what A.6.2.7 covers. Five decisions run in parallel: which systems and versions, which audiences, which teams, and which upstream components. The statement of applicability under clause 6.1.3 must record why this control is included and what its scope is, and these choices shape the workload far more than any documentation tool.

Which AI systems and versions

Decide which AI systems, and which material versions of each, need technical documentation. A new model, a changed training approach or a new intended purpose usually counts as material, while a cosmetic interface change often does not. Write the threshold down so that teams can test each release against it. Include internal tools, pilots and systems built on a third-party model, because a system is in scope whether it was built in-house or assembled from parts. Confirm the inventory from A.4 resource records matches what the documentation program covers.

Which interested party categories

Map each category of interested party that needs information: users, operators who run the system, partners that integrate it, customers that buy it, and supervisory authorities that may ask for it. Each group needs different content. A supervisory authority may need design rationale and evidence of testing, while a user needs limits and safe-use instructions. Record the decision per category, so the statement of applicability can show why each audience was included or left out.

Which teams produce and maintain content

Assign named owners for each document section: engineering for architecture and training approach, data teams for dataset descriptions, the risk function for known limits and residual risks, and product or legal for user-facing wording. Documentation written by one team and left to drift is the most common reason records fail to match the deployed system. Set a review step before each material release so that the people who change the system also update the record, and confirm who signs off.

Which third-party documentation to pass on

List the models, datasets, APIs and components the organization uses that come with their own documentation, such as model cards or supplier technical sheets. Decide which of that material must be passed to downstream parties, and which can only be referenced. Check the license and contract terms before redistributing supplier content. Where a supplier provides no documentation, record that gap as a residual risk rather than leaving it unstated, since the organization still owes its own audience an accurate picture.

Which limits and residual risks to disclose

Decide which known limitations, failure modes and residual risks each audience must see, and how they are phrased for that audience. Limits drawn from testing and impact assessment under A.5 should be traceable to the documented decisions. Confirm with legal and risk owners what counts as sufficient disclosure for each jurisdiction and contract, because the scope of disclosure is a judgment the organization owns, not something a tool can settle.

How an assessor tests A.6.2.7 technical documentation

This table walks through the five steps an assessor typically takes to test A.6.2.7, with the evidence each step requests and the findings that recur. Read each row as a question the assessor will ask, then check whether your records answer it for the systems in scope.

Test step	Evidence requested	Common findings
Confirm interested party categories and their documentation needs	Register of interested party categories (for example users, partners, supervisory authorities, internal operators), the documentation each category needs, and the approval record for that list	Categories listed without any stated documentation need, or a list copied from a template that does not reflect the organization's actual AI systems
Sample AI systems and check each audience's documentation exists in a suitable form	For each sampled system, the documentation set per audience, with format, language, level of detail and where it is published or delivered	Only one technical document exists for all audiences, or documents exist but are not reachable by the audience they were written for
Check documented limits and residual risks against the risk assessment and verification results	Limitations statement, known failure modes, residual risk entries, and the matching risk assessment and verification or red teaming outcomes for the same version	Generic limitations such as 'the model may make mistakes' with no stated conditions, populations or tested boundaries; residual risks absent from the risk register
Check version control and that documentation matches the deployed system	Version history showing who changed each document and when, release records linking each document version to a deployed model or system version, and change approvals	Documents describing a version no longer in production, or edits made without a recorded approval or link to the release
Check ownership and review	Named owner per document, review schedule or trigger events, and evidence that reviews occurred after material changes, incidents or new interested party requests	Owners who have left the organization, no review trigger defined, or review records that are signed but do not show what was checked
Check documentation reuse across audiences	Audience-specific versions or sections, and a record of how shared content was adapted for each category	Internal engineering documentation handed to users or supervisors without adaptation, or customer-facing claims that the internal records do not support

Implementing A.6.2.7 technical documentation in six steps

This sequence turns A.6.2.7 into a repeatable process that identifies who needs documentation, produces a defined set for each audience, and leaves evidence that an assessor can trace from each system back to its requirements.

Identify interested party categories and their information needs
Start by listing every category of interested party that touches the AI system, such as end users, business customers, integration partners, internal operators, and supervisory authorities where a regulator applies. For each category, record what it must know to use, integrate, oversee or challenge the system safely. Product management, legal and security should agree on the list, because a missing category usually means a missing document later. The step is done when each category has a named purpose and a short statement of its information needs, approved by the system owner.
Define the documentation set for each audience
Translate the needs list into a defined set of documents, one set per audience. An illustrative set might include a user guide for operators, a partner integration note covering interfaces and dependencies, and a regulator-facing technical file that holds the design, data and testing records. Assign each document a scope, a required content outline and a declared audience so that nothing is written for everyone at once. The step is complete when the set is listed in the system's documentation register and each document has an approved outline.
Document intended purpose, limitations and residual risks
Pull the intended purpose, known limitations, conditions of use and residual risks from existing records instead of writing them from memory. The impact assessment shows who may be affected and where harm is possible, while verification and validation results show where the system fails or performs poorly. Reference the ISO/IEC 23894 risk guidance and the NIST AI RMF crosswalk to B.6.2.7 when you need a vocabulary for residual risk. Record each limitation with the test or assessment that found it. The step is done when every limitation and residual risk in the documents traces to a source record and an accountable owner has accepted it.
Set the form and location for each document set
Decide the format, versioning and access rules for each set. Users may need searchable web pages, partners may need a versioned PDF with an interface specification, and regulators may need a controlled archive that can be produced on request. Choose a location that keeps history: a wiki with version control can record what changed, when and by whom, and a documentation platform with role-based permissions can limit who edits and who reads each book or page. Confirm with each platform's documentation that it supports these features in your configuration. The step is complete when each set has a named location, an access model and a retention rule recorded.
Assign owners and a review trigger tied to releases and monitoring
Name one owner for each document and one owner for the set as a whole, and define the events that force a review. Releases, material model or data changes, significant incidents, drift findings and changes in intended use should each trigger a check of the affected sections. Link the review trigger to the change process and the operation and monitoring records under A.6.2.6, so that documents do not drift from the system they describe. The step is done when ownership and triggers are written into the procedure and the first owner has confirmed the review calendar in the change tool.
Run a first internal check against a sample system
Before the external assessment, pick one representative AI system and test the documentation set against it. Have someone who did not write the documents follow each audience's view and ask whether the content answers the stated information needs, whether each limitation traces to evidence, and whether the version shown matches the deployed system. Record gaps, correct them and file the findings with the change history. Treat this check as the first full pass through the cycle. Once it is done, the organization can rely on steps 3 to 5 for each later release, because the sequence only needs to run in full once. The step is complete when the sample check is signed off and open findings are closed or accepted.

Evidence that passes A.6.2.7 and how to keep it current

Assessors test A.6.2.7 by comparing artifacts, not by reading each one in isolation. The cards below cover the records that should exist for every AI system in scope and the checks that show they agree with each other. Keeping them current depends on tying reviews to releases and monitoring events rather than to a calendar.

Interested party map and documentation matrix

This is the starting record: a list of each category of interested party, such as users, partners, operators and supervisory authorities, with the documents each one needs and the form it receives them in. Assessors use it to see whether the organization made the determination the control asks for, or whether documentation was written by habit. Check that every party named in the matrix maps to at least one document, and that no document exists without a named audience. Owners should sign the matrix at each significant change to the system.

Audience-specific documents with version history

Each document in the matrix should exist in the form its audience needs, such as a user guide, a partner integration sheet or a regulator submission pack, with a visible version and a change log. Version history matters because assessors ask which text was in force when a given release shipped. Wiki platforms with per-page revisions and the ability to compare versions make that trail easy to show. Confirm the platform records who changed each page and when.

Limits and residual risk section

The limitations section states what the system should not be used for, where its outputs are unreliable, when human oversight is required, and which risks remain after controls are applied. It must trace back to the risk and impact assessment, so every residual risk named in the documentation appears in the risk register with an owner. Mismatches here are among the most common findings, because the documentation says one thing and the risk record says another. Review this section against each new evaluation result.

Approval and review records per release

Every release that changes model behavior, data, intended purpose or documented limits needs a record showing who reviewed the technical documentation, what changed, and who approved it to ship. The record should point to the exact documentation version the release used. Without this link, an assessor cannot confirm that the published documents match the system in production. Ask the release owner to confirm where these records are stored and that they cannot be edited after approval.

Distribution records by audience

Distribution records show what each audience received, which version they received, and when. They answer the question of whether a partner or supervisory authority had the limits statement that applied at the time of use. Keep a log per recipient group, and record withdrawals or superseded versions as well as new issues. Access controls on the documentation space should match the audience map, so that restricted material is not visible to parties who should not see it.

What A.6.2.7 technical documentation costs to meet

This table compares the cost components of meeting A.6.2.7, who is paid for each one, whether it is one-time or recurring, and what moves it up or down. No price or duration is stated because none has been published for this control, so use the rows to structure a quote request. The main takeaway is that audience-specific writing and reviewer time usually cost more than tooling, and they recur with every release.

Cost component	One-time or recurring	What drives it	How to keep it down
Writing audience-specific documentation	One-time build, then recurring per release	Number of named audiences, number of AI systems in scope, and how many distinct content sets each audience needs	Keep one core technical record per system and derive audience views from it rather than writing each set from scratch
Mapping limits and residual risks to risk and impact records	One-time mapping, recurring updates	Number of identified limitations, knowledge limits and residual risks already recorded in the risk and impact assessments	Reuse existing risk register entries and link them by identifier so changes update both records
Documentation tooling	Recurring for hosting and administration, one-time for setup	Choice of platform, hosting location, access model, and time spent administering backups, upgrades and permissions	Self-hosted open-source wikis can remove license spend, but confirm hosting, backup and administration effort in your own environment before comparing
Reviewer time from engineering, legal and product	Recurring per release	Number of reviewers per document, depth of technical content, and whether reviews are scheduled or ad hoc	Assign named reviewers per section, set review checkpoints in the release process, and record approvals in the document history
External review of the documentation set, if bought	Optional, usually one-time with periodic repeats	Volume of documentation, whether the reviewer must test technical claims, and whether legal review is included	Limit external review to the audiences and claims with the highest exposure, and agree the review scope in writing
Auditor sampling time	Paid through the audit engagement, recurring per audit cycle	Number of AI systems sampled, the depth of documentation checked, and the number of follow-up requests	Keep documentation traceable from each system to its audience versions and risk records so samples can be answered quickly

Using open-source wikis, logs and test tools as documentation evidence

Four open-source tools can produce records that support A.6.2.7 documentation: version history, controlled access, test output and runtime traces. Each covers one kind of evidence, and none decides what documentation is adequate for a given audience. The organization still has to define the content, the audiences and the limits.

Version history in XWiki

XWiki keeps every change to a page under version control, recording what changed, when and by whom. Users can compare any two versions and roll back to an earlier one. For A.6.2.7, this gives assessors a dated history of each audience document, showing when a limitation or residual risk statement was added, revised or removed. Check with the project that the version history, diff and rollback behavior matches your edition and configuration, and confirm how long history is retained in your deployment.

Audience access in BookStack

In BookStack, a user's abilities come from the roles assigned to them, and permissions can be overridden at the shelf, book, chapter or page level. This lets you separate, for example, a document set for supervisory authorities from one for customer integrators. The evidence is the permission configuration itself, which you should export and review. Confirm with the project how overrides interact when a user holds several roles, since that determines who can actually read each document.

Probe results from garak

garak probes language models for hallucination, data leakage, prompt injection, misinformation, toxicity generation and jailbreaks. It writes a JSONL report of every attempt and evaluation, plus a hit log of attempts that found a vulnerability. These outputs can feed the limits and residual risks section, where you state which failure modes were tested and what remained. A clean run does not prove absence of risk. Record the probe set, version and configuration used, and confirm current probe coverage with the project.

Runtime traces in Langfuse

Langfuse traces capture every operation in a request, including LLM calls, retrieval steps, tool executions and custom logic, with timing, inputs, outputs, token usage and metadata. For A.6.2.7, traces can show whether a deployed system behaves within the limits you documented, such as which tools it calls or how it handles out-of-scope requests. Decide which fields contain personal data before enabling capture, and confirm retention and masking options with the project for your hosting setup.

Who writes, reviews and assesses the documentation

Your organization owns A.6.2.7 from start to finish. The control asks you to decide which categories of interested parties need technical documentation and what each of them needs, so that decision is a management responsibility that a partner can inform but cannot make on your behalf. Your team also approves each audience's content before it is released and keeps it aligned with the system as it changes.

Interested party map: Maintain a documented list of audiences, such as users, deploying customers, partners, internal operators and supervisory authorities, with the information each one needs.
Content approval: Assign a named owner who signs off each version of each audience's documentation, including the stated limits and residual risks.
Currency checks: Set a trigger for updates whenever the model, data, intended purpose or known limitations change, and record who performed the review.
Accuracy of claims: Confirm every performance statement and limitation against your own test results, not against vendor marketing or a partner's summary.

Before relying on the documentation, check that the interested party map names an accountable owner and that each approval is recorded with a date and version.

Where A.6.2.7 documentation usually falls short

Technical documentation under A.6.2.7 fails less often from missing content than from content that goes stale, serves the wrong reader, or hides limits. The five gaps below recur across AI systems, and each one has a closing action that an assessor can see in the records.

Documentation written once, never updated

Teams often produce a model card or system description at launch and leave it alone through retraining, prompt changes and new tool integrations. An assessor will compare the document's version history with the release history and ask why they differ. Close it with a release checklist that blocks publication until the technical documentation has been reviewed against the change, with the reviewer and date recorded in the wiki's version history.

One document serving every audience

A single document that mixes architecture detail for engineers, decision guidance for deployers and summaries for regulators tends to satisfy none of them. Partners need integration constraints, users need intended use and warnings, and supervisory authorities need traceable design and testing decisions. Map each audience to its own page with a short statement of what that group needs, and link the pages to one shared source of truth.

Limits stated in vague terms

Phrases such as "may not perform well in some cases" give users nothing to act on and give an assessor nothing to test. Limits should name the input conditions, populations or languages where performance was measured, and the observed failure modes. Tie every stated limit to a named test result from the verification and validation records, so each claim can be traced to evidence and re-run after a change.

Residual risks missing from user material

Teams often document residual risk in an internal risk register and omit it from the material users read. Users then operate the system without knowing which errors remain after controls are applied and what human oversight is expected. Carry each accepted residual risk into the user-facing documentation with the mitigation the user must apply, and confirm that the register and the user material were reconciled at the last review.

No record of what each audience received

When a limit changes, the organization must be able to show which partners and customers received the earlier version and when they received the update. Without a distribution record, the organization cannot demonstrate that the information reached the right parties. Keep a distribution log that records the document version, recipient group, delivery date and the acknowledgment received, and retain it with the release records.

What buyers ask about A.6.2.7 documentation cost and effort

How much effort does A.6.2.7 documentation take for one AI system?

The effort depends on how many audiences need documentation, how often the system is released, and how much verification evidence already exists. No general figure applies, and no duration is supplied for this work. Each audience, such as users, integration partners and supervisory authorities, needs its own form of documentation, so the number of audiences multiplies the writing and review. Frequent releases mean the documentation must be updated against each version, which recurs. A team with complete test records, model choices and design decisions can draw on them directly. A team that must reconstruct those facts first will spend most of its effort on discovery rather than writing. Ask your team to inventory the audiences and the records they already keep before estimating anything.

Can a team meet A.6.2.7 without outside help?

Yes, a team can meet A.6.2.7 without outside help if it owns the content and has a reviewer who can check it for accuracy. The control asks the organization to decide what each interested party needs and to provide it in a suitable form, so the decisions and the content must come from people who know the system. Outside help is most useful for structuring the documentation set, setting up version control and running a gap review against the requirement. The organization still owns every statement about limits and residual risks. An independent auditor or certification body, not a consultant, decides whether the evidence is sufficient for any certification.

What does the work need from engineering, product and legal?

Each function contributes different content, and the work stalls if one function is missing. Engineering provides architecture, model and data descriptions, test results, monitoring behavior and known failure modes. Product defines the intended purpose, the intended users, the supported use cases and the uses the organization excludes. Legal or compliance reviews the statements about limits, obligations to users and partners, and how residual risks are described. Someone must also own the document set itself, assign reviewers, and confirm that each release has an updated version. Agree on these roles in writing before work starts so that reviews do not wait on availability.

How long does A.6.2.7 documentation take to produce?

The duration depends on the existing records and the scope, and no duration is supplied for this work. A system with well-kept design records, test results and an agreed list of audiences can be documented far faster than one whose decisions were never written down. Scope also matters: a single internal audience needs less than several external audiences with different levels of detail. Ask for a timeline that lists the records to be reviewed, the audiences to be covered, the review cycles and the release at which the documentation is first complete. Treat any timeline offered without those inputs as unverified.

Do open-source tools remove the cost of A.6.2.7 documentation?

Open-source tools remove license spend, but they do not remove hosting, administration or writing effort. A wiki or documentation platform with version control can record what changed, when and by whom, and it can compare and roll back versions. Permissions can be set by role at the page or book level, so reviewers see only what they need to approve. Someone still has to host and back up the platform, configure roles, maintain templates and write the content itself. For a team with no existing documentation practice, those ongoing tasks are often the larger cost. Confirm the hosting and administration responsibilities before choosing a tool.

What should a partner put in a written scope for A.6.2.7?

A written scope should list the deliverables, the systems covered and the responsibilities of each party. Ask the partner to state which audiences the documentation will serve and the form each audience receives. The scope should name the records the partner will review, the number of review cycles, and how updates will be handled at each release. It should also say which content the organization must supply, who approves it, and what the partner will not do. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and a quote follows from that scope. Make sure the document states that the organization owns its controls and that an independent auditor or certification body issues any report or certificate.

How DeployOpen prepares A.6.2.7 documentation evidence

DeployOpen helps organizations set up the systems and records that hold A.6.2.7 AI system technical documentation, inside their own infrastructure. The organization decides which documentation each interested party needs, and DeployOpen prepares the platforms, workflows and evidence that show those decisions are carried out.

How we scope

Engagements are fixed-scope, with the documentation audiences, systems and deliverables agreed in writing before work starts.
The written scope names which AI systems, interested party categories and documentation types are covered for A.6.2.7.
Scope also records the limits and residual risk content the organization expects each document to carry.

How we build

DeployOpen sets up a version-controlled documentation space in the client's own environment, with recorded authors and change history.
Role-based permissions are configured so each audience sees the documents it is entitled to, and no more.
Templates cover intended use, known limits, human oversight measures and residual risks, aligned to the organization's own decisions.

How we hand over

Handover includes the documentation register, access model, review workflow and a record of who approved each document version.
Test artifacts such as red-team or evaluation reports are linked from the documentation so assessors can trace claims to evidence.
Auditors and certification bodies receive the evidence directly from the organization, since DeployOpen does not issue reports or certificates.

How we support

Ongoing support and upgrades can be retained after handover, covering platform changes and documentation review cycles.
Retainers can include periodic re-testing of AI systems so documented limits and residual risks stay current.
Organizations should confirm with DeployOpen during scoping which support terms, response expectations and deliverables apply.