Technical documentation is the engineering chore nobody schedules
The blank document was the problem. Not the model, not the tests - the blank document where I was supposed to write down what we had built. I maintain a system on the provider side of an AI feature, and Article 11 of th
The blank document was the problem. Not the model, not the tests - the blank document where I was supposed to write down what we had built.
I maintain a system on the provider side of an AI feature, and Article 11 of the EU AI Act asks for technical documentation drawn up before the system goes on the market. Annex IV describes what that documentation contains: a general description of the system, the design and development process, the data requirements and provenance, the validation and testing procedures, the risk management measures, the human oversight design, the accuracy and robustness characteristics, the compute needs, the change history. None of it is exotic. All of it is the stuff engineers know and never write down.
The documentation is mostly recovered memory
Here is what actually happens. The descriptions live in a design doc from eight months ago, three pull request discussions, a Slack thread about a threshold, and one engineer's head. When someone finally asks for the Annex IV set, the work is archaeology. You are not writing documentation; you are reconstructing decisions that were never recorded as decisions.
I tried a template. I made rows for each Annex IV item and three columns: what the article asks for, what we have, and whether a document exists to prove it. The third column was the useful one. The gap was almost never "we did the wrong thing"; it was "we have no artefact for this row". That is a work queue, not a failure, and a work queue is something I can actually assign.
The manual template had two problems. Re-reading the article kept surfacing items I had folded into other rows, and every system meant starting over from memory. I was hand-building the same ask-list repeatedly, which is exactly the work that should be a draft, not a craft.
What I built
I built TechDocKit to produce that draft. You paste how you provide or deploy a system and it returns an Article 11 / Annex IV technical-documentation demand pack: a decision-support draft of the documentation (the "Act draft") and the evidence gaps where your account has nothing behind it. That is the whole feature set. It does not read your repository, does not run your tests, and does not certify the system.
I kept the gaps as a first-class output, not a footnote. A draft that only lists the Annex IV elements is a reading list. A draft that also marks, per element, whether you hold an artefact is a backlog: two documents to write, one owner to assign, one row where the honest answer is "we don't know yet". "We don't know yet" is a fine state for a draft to report and a bad state to discover during a review.
The draft is deliberately coarse. Paste one sentence and you get a thin draft back, because the tool cannot invent a validation procedure or a data lineage you never described. I would rather it under-produce than confabulate a plausible-looking section that nobody can defend.
The limits, stated plainly
This is a decision-support tool. It is not legal advice, not a certification, and not a live audit harness. It does not observe your system, does not decide whether your system is high-risk, and does not determine which Annex IV elements apply to your classification. Whether Article 11 applies depends on classification under the Act, and that belongs with someone who can read your actual deployment. I am referencing a real article and a real annex - not a deadline, not a fine, and not a promise that a filled-in draft makes a system compliant.
I also want to be clear that "evidence gaps" is descriptive, not a verdict. The tool shows where your pasted account is thin relative to the ask-list. It has no access to the artefacts themselves, so it cannot tell you whether a document you do hold is any good. A row marked as a gap means "nothing was described here", not "you failed this requirement".
If your technical documentation is currently a folder of half-remembered decisions, TechDocKit gives you a paste-first draft and a gap list to work from. If the Annex IV set has an element you think the draft missed, that is a bug and I would like to hear about it.
FAQ
What does it produce?
An Article 11 / Annex IV demand pack: a decision-support documentation draft and an evidence-gaps list. You paste how you provide or deploy a system into TechDocKit and get the draft back.
Does it check whether we are compliant?
No. It does not read your repo, run your tests, or certify anything. It drafts the asks and marks where your account has no artefact behind it.
Is this legal advice or a certification?
Neither. It is decision-support - not a certification, not a legal opinion, not a live audit harness. Whether Article 11 applies depends on your system's classification.
Do I need this if my system is not high-risk?
Probably not. The Article 11 documentation duty is tied to classification under the Act. If that is not your situation, the demand pack will produce a draft you do not need.
Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.