What an auditor, or Sekit's evidence engine, asks for.
AI system technical documentation
The versioned documentation pack for a specific AI system: the requirements it must meet, how it is designed or configured (model, architecture or vendor, data used, decisions made), and the technical detail needed to operate, assess, change and retire it safely.
From the Sekit evidence catalog
In practice
Requirements for an AI system have to say more than "it should work well": who will use it, what it must not do, what data it needs, and what risk treatments (a human review step, a confidence threshold) follow from the impact assessment. The AI system technical documentation captures this before build or configuration starts. Auditors look for whether a requirement is testable, "the model must flag low-confidence answers for review" rather than "the model should be accurate", and whether the threat model considered AI-specific risks like prompt injection, not only standard application threats.
Common gaps
Requirements describe the intended use but never translate the impact assessment's identified risks into testable constraints.
Threat modeling covers the application layer but skips AI-specific risks such as prompt injection or data leakage through the model.
A vendor AI tool was adopted with configuration choices made ad hoc, with no documented requirements to check them against.
Questions your auditor will ask
Where do the stated requirements for an AI system come from?
Intended use, stakeholder needs and the risk treatments from the impact assessment, all recorded in the AI system technical documentation.
Are the requirements testable, or only stated as goals?
Each requirement has a pass condition, for example a defined confidence threshold that triggers human review, not only a general aspiration.
Does your threat modeling cover AI-specific risks?
Yes, prompt injection, training or input data exposure, and model misuse are considered alongside standard application threats.
How are these requirements applied when the AI is a purchased tool rather than custom code?
The same requirements process applies to configuration choices for vendor tools, documented before the tool is approved for use.
Where regulation demands it
NIS2 art. 6.2 (Secure development life cycle) covers this, which for an AI system starts at the requirements and threat-modeling stage.
Related controls
Via the shared Sekit CSF topic, not the framework's own index.