AI governance evidence for DPOs and AI governance officers

The EU AI Act's Article 9 requires a documented risk management system for high-risk AI: identify foreseeable risks, evaluate and mitigate them, test before deployment, and monitor after. Each step requires a record. Without a structured tool, DPOs are producing these records manually — in Word documents, spreadsheets, and email threads.

ISO/IEC 42001's clauses 6 and 8 require per-system risk assessment, control planning, impact assessment, and operational records. The standard does not prescribe a specific format — but an auditor will expect a structured, versioned document for each AI system in scope.

Your AppSec lead or security architect runs the review in five steps: Model (Drel rebuilds the system from its repository and design docs), Threat model, Attack (the attack paths through the system, derived from its design), Fix (the proposed fix in the Jira ticket, the merged pull request checked) and Monitor (re-checked when the code changes). You sign the security clearance it produces.

For every AI system assessed through Drel, the output maps directly to regulatory evidence requirements:

• Risk register (ISO 42001 clause 6.1.2, EU AI Act Article 9). AI-specific risks identified for the system — not generic, but specific to the architecture, tools, and data flows in its repository and design docs.
• Control plan (ISO 42001 clause 6.1.3). Required controls mapped from the risk register, with implementation status and evidence links.
• Control checks before deployment (EU AI Act Article 9). The attack paths behind the risk register, and the controls Drel can verify in the code; a missing control is a control gap, and its proposed fix goes to the Jira ticket. A reviewer decides what counts as evidence of the control.
• Technical documentation support (EU AI Act Article 11). Drel's Model step rebuilds the system from its repository and design docs and captures system description, design specifications, data flows, and tool definitions in a format that supports Article 11 requirements.
• Clearance decision (ISO 42001 clause 8). The operational record with disposition, conditions, and re-assessment triggers that defines when the system must be reviewed again.
• Sign-off record. Who reviewed, when, on what version, with what conditions — the governance trail your auditor will ask to see.

If your organization uses a General-Purpose AI model (GPT-4, Claude, Gemini) as the base of an application, your deployer obligations under Article 9 apply to the application — not just the model provider. Drel reviews the application layer: the integration code, retrieval pipeline, tool surface, and deployment context that you own and are responsible for.

The EU AI Act requires maintaining an inventory of AI systems and re-assessing them when they change. Drel's dashboard gives you portfolio-level visibility across all assessed systems, with named re-assessment triggers that fire when a model changes, a new tool is added, or a scope expansion occurs. Drel re-checks each clearance when the code changes, with a gate in your CI, and agents can ask for it over MCP.

You can see which systems have open re-assessment triggers, which clearances are conditional, and which have blockers that must be resolved before the system is cleared for the next lifecycle gate — all from a single view.