Documentation Obligation

This page explains how the site’s own articles describe the documentation obligation. It is not legal advice, and a qualified lawyer should confirm what applies to a particular system.

What the documentation obligation is

The documentation obligation is the duty the EU AI Act places on a high-risk AI system to be documented and to have a risk management process. The HR training article says a system in the high-risk category carries a documentation and risk-management obligation whichever platform runs it.

The site’s pages do not set out what the documentation for a high-risk system must contain, and this page does not either. What they do give is the shape of the duty: what it attaches to, who carries which part of it, what a business that only uses a system still has to do and what kind of records are worth keeping whatever the classification turns out to be.

What the duty attaches to

The obligation attaches to the system and its risk, not to a supplier or a hosting choice. The high-risk AI system page says a system in that class needs a risk management process and documentation whichever way it is run, whether it is hosted by a business itself, called through an API or bought off the shelf.

Classification therefore comes first. The governance article says the Act draws its line at what the AI is used for. A small organisation deploying AI for a use the Act classes as high-risk carries the same core obligations as a large one running the same use, whatever its headcount or turnover. Recruitment and candidate evaluation are the clearest example the site gives, and the recruitment AI page covers it.

Who carries it, the provider or the Deployer

The governance article says the heaviest obligations generally sit with the vendor that develops a high-risk system, not with a business that deploys an existing one. It names a full risk management system run across a product’s lifecycle, representative training data and built-in logging. The site’s summary of this term says the same of building and certifying: that cost sits with the vendor that develops the system.

The article adds a warning that appears across the site. “The vendor handles compliance” is not itself a defensible answer, because a deployer still carries duties of its own. The review of the EU AI Act and GDPR makes the same point: a business that buys a tool does not buy its way out of responsibility.

What a Deployer still has to do

The ownership article lists a deployer’s duties for a high-risk system. A deployer must:

• monitor the system for anomalies, dysfunctions and unexpected performance;
• keep the system’s logs for at least six months;
• assign competent people to oversee it;
• inform the provider and the authorities if there is a serious incident.

The article’s observation is that each duty presumes a person. Monitoring needs someone monitoring, and oversight needs someone assigned. A business that has not decided who that is will find a deadline arriving without an answer. That is why it argues that an owner has to exist before the duty applies. The AI ownership page covers the named person, and the audit trail page covers the logs.

Does it apply to a Small Business

Yes, where the use is high-risk. The governance article says small size is not an exemption. It also says most day-to-day small business use, such as drafting, summarising and internal search, sits outside the high-risk category altogether. The only way to know which use is which is to classify each one, which is the point of risk classification.

The review of the EU AI Act and GDPR lists meeting the documentation rules for high-risk use among a business’s key duties, alongside classifying each use, overseeing it and keeping staff AI literate. For most small businesses, the first and larger task is the classification, because it decides whether the obligation applies at all.

Dates and the simplified route

The governance article reports that, under the Digital Omnibus agreement, the compliance deadline for stand-alone high-risk systems under Annex III moved from 2 August 2026 to 2 December 2027. A simplified compliance framework was also extended to qualifying small mid-cap companies, easing the documentation burden for firms in that band. The article gives the definition of that band, and this page leaves it there.

Its reading is careful. The extension buys time and eases paperwork, but it does not remove the requirement to classify a use case correctly and manage the risk it carries. The high-risk deadline page covers the dates. Dates have moved before and may move again, so confirm the current position with an adviser.

Records worth keeping for every AI use

Whatever the classification turns out to be, the site recommends a short written record per AI use. The review says it should state what the tool does, what data goes in, which account type is used, who reviews the output and what the risk tier is. It says a record like that answers most of the questions a customer or regulator would ask, and that one line per use is a start.

The ownership article gives a close version for each tool: its purpose, its users, the data it can reach and the date of its next review. It asks that the record also say who checks the output and how often, because a rule that says “a person should check the output” is a hope and not a control. It describes a sequence a small business can finish in a month: list every tool, name an owner for each, write the one-page record and set a review date.

The recruiting article applies this to a pilot. It says the notes kept while testing a tool are the start of the record the AI Act will expect deployers to hold, and that they answer the question of why a particular tool was chosen. The AI governance page covers the wider policy that sits around these records.

Asking a vendor about its documentation

Because the heaviest part sits with the vendor, a business using a high-risk system has a reasonable question to put to it. The high-risk AI system page says a deployer should ask what the vendor’s documentation covers, and should keep its own record of its own duties. The recruiting article gives six questions for a hiring tool, including whether it shows why it ranked a candidate, whether a person can override every decision, what it does automatically, how it is tested for bias, where candidate data is stored and what logs it keeps.

The article says to write down the answers and to treat vague ones as information. A vendor that cannot say what its documentation covers, or what logs the system keeps, has told the business something about how much of the work will fall back on it.

A worked example

An illustration, not a case study. A small business uses two AI tools. One drafts internal emails. The other scores incoming job applications.

The business lists both and classifies each use. The email tool is a drafting use that a person reads before sending, so it sits outside the high-risk category and needs a light check and a one-line record. The scoring tool is a recruitment use, so the business treats it as high-risk and takes advice.

For the second tool, the business asks the vendor what its documentation covers and what logs the system keeps, and writes down the answers. It names one person as owner, with authority to pause the tool. That person is the one who monitors the system and who is assigned to oversee it. The business keeps the system’s logs for at least six months where it controls them, and writes a one-page record: purpose, users, the data the tool reaches, who checks the output and the date of the next review.

When a candidate later asks how a decision was reached, the business has a record, a named owner and a person who made the call. It did not have to produce the vendor’s documentation itself. It did have to be able to show its own part.

Mix-ups worth avoiding

Four confusions come up often enough to name. The first is assuming the vendor carries all of it, when the sources say a deployer keeps duties of its own. The second is treating the delay to 2 December 2027 or the simplified route as a removal, when the governance article says it eases paperwork and buys time without removing the requirement. The third is assuming every AI tool carries the obligation, when most everyday use sits outside the high-risk category and classification decides. The fourth is treating this page as a checklist of what the documentation must contain, when the site’s pages do not list that and a qualified adviser should be asked.

How we use it

The site’s pages do not set out the full contents of the documentation, so this page is a pointer and not legal advice. The governance article says the only way to know whether a use case is high-risk is to classify each one, rather than assume small size is an exemption. The review suggests one short record per AI use either way.

If you would like an outside view on which of your AI uses might be high-risk and what each carries, a discovery call is a quick way to start. An audit is a diagnostic and not a legal opinion, so it identifies the obligations without certifying them.

Sources

• AI training for HR teams: what should it cover?: a high-risk system carrying a documentation and risk-management obligation whichever platform runs it.
• EU AI Act vs GDPR: meeting documentation rules among a business’s key duties, the short written record per AI use and the vendor not carrying everything.
• AI governance for small and mid-sized businesses: the Act applying by use and not size, where the heaviest obligations sit, the moved Annex III date and the simplified route for qualifying small mid-cap companies.
• What happens when nobody owns the AI you have rolled out: the deployer duties, the six months of logs, the named owner and the one-page record.
• Best AI for recruiting: the pilot notes as the start of the deployer’s record and the vendor questions.
• High-risk AI system, EU AI Act, Deployer, Audit trail, Recruitment AI, High-risk deadline, Risk classification, AI governance and AI ownership: the neighbouring terms this page links to.