Portfolio

Responsible AI Governance Dashboard

A dashboard concept that helps organizations monitor AI systems for risk, compliance, human oversight, data quality, and user trust.

Try the live demo
Responsible AIEU AI ActGDPRGovernance
Role
AI Governance Product Designer
Project type
Governance & Product Concept
Duration
4 weeks
Tools
Figma, Miro, Notion, Excel
Responsible AI Governance Dashboard visual summary

01

Executive Summary

The dashboard gives an organization one place to answer the questions an auditor, a data protection officer, or a board member will ask: which AI systems do we run, who owns them, what risk level do they carry, is oversight defined, and what has gone wrong so far.

02

Business Problem

Companies adopting AI often lack a central place to monitor AI risks, approvals, user feedback, compliance status, and model performance.

03

Stakeholders

  • Data protection officer
  • Compliance and legal
  • System owners
  • IT security
  • Management and board
  • Employees using AI systems

04

Discovery and Research

  • Existing AI and automation tools in use, including unofficial ones
  • Current approval process before launch
  • EU AI Act classification needs
  • Logging and retention practices
  • How incidents are reported today

05

Objectives

  • Maintain a complete inventory of AI systems
  • Assign a risk level and an owner to every system
  • Make the pre-launch checklist visible and auditable
  • Track user trust signals over time
  • Record incidents with root cause and action taken

06

Proposed Solution

A governance workspace with five sections: system inventory, risk classification, compliance checklist, user trust metrics, and incident log. Each system has an owner, a risk level, and a status, and nothing reaches production status without a completed checklist.

V

Visual analysis (D3)

Every figure below is generated with D3 from this case study’s own data and is annotated using Tamara Munzner’s what / why / how framework: the data abstraction, the abstract task it supports, and the visual idiom with its marks and channels.

V1Risk exposure by impact

  • High
  • Medium
  • Low

What — dataItems are identified project risks; one ordered attribute (impact) and one categorical attribute (mitigation, on hover).

Why — taskRank the risks and identify the extremes that need mitigation first.

How — idiomDot plot: point marks, position on a common ordered scale as the primary channel, colour hue as a redundant encoding.

V3Implementation sequence

What — dataItems are roadmap phases with an ordered key (sequence) and a quantitative attribute (workstreams per phase).

Why — taskSummarise the delivery order and see where the workload concentrates.

How — idiomGantt-style ranged bars: line marks with length encoding magnitude, aligned on a shared horizontal scale, colour separating phases.

V4Solution architecture as a network

What — dataA node-link network: nodes are architecture components, links are data flow, and layer is a categorical attribute.

Why — taskExplore topology — trace a path from data source to governed output and locate dependencies.

How — idiomLayered node-link layout: rectangle marks positioned by layer, connection marks for flow, greyscale luminance separating adjacent layers.

V6Engagement depth profile — radar

  • Documented items

What — dataOne item (this project) with seven quantitative attributes: the number of documented artefacts per workstream.

Why — taskSummarise the shape of the engagement and compare workstreams — which parts are deep and which are thin.

How — idiomRadar/star plot: line and point marks, angle channel for the attribute key, radial distance for magnitude.

V7Roadmap workload — circular barplot

  • Workstream items

What — dataItems are roadmap phases with one ordered key (sequence) and one quantitative attribute (workstream items).

Why — taskCompare how much work each phase carries and see the cycle of delivery as a whole.

How — idiomCircular barplot: arc marks, angle for the ordered phase key, radial length for magnitude.

V8Architecture composition — treemap

  • Component
  • Layer

What — dataA hierarchy: architecture layers containing components, each component counting as one unit.

Why — taskSee where the system's weight sits — which layers hold the most moving parts.

How — idiomTreemap: containment for the hierarchy, area marks sized by component count, nested rectangles for layers.

07

System Architecture

+---------------------------+
|  AI system inventory      |
|  name, dept, vendor,      |
|  data, owner, status      |
+---------------------------+
        |
        v
+---------------------------+
|  Risk classification      |
|  low / medium / high /    |
|  not allowed              |
+---------------------------+
        |
        v
+---------------------------+     +----------------------+
|  Compliance checklist     | --> |  Trust metrics       |
|  GDPR, DPO, oversight,    |     |  acceptance, appeals |
|  logging, AI Act, bias    |     |  survey score        |
+---------------------------+     +----------------------+
        |
        v
+---------------------------+
|  Incident log             |
|  severity, cause, action  |
+---------------------------+

AI System Inventory

  • System name
  • Department
  • Vendor
  • Risk level
  • Data used
  • Owner
  • Status

Risk Classification

  • Low risk
  • Medium risk
  • High risk
  • Prohibited / not allowed

Compliance Checklist

  • GDPR review completed
  • Data protection officer approved
  • Human oversight defined
  • User information available
  • Logging enabled
  • Vendor agreement reviewed
  • EU AI Act classification completed
  • Bias testing completed

User Trust Metrics

  • Acceptance rate
  • Rejection rate
  • User complaints
  • Trust survey score
  • Explanation requests

Incident Log

  • Incident date
  • Description
  • Severity
  • Affected users
  • Root cause
  • Action taken
  • Status

08

UX Design

The dashboard is designed for a non-technical owner. Status is expressed as a decision — approved, blocked, needs review — rather than as raw model metrics.

Screens

  • Portfolio overview with risk distribution
  • System detail with owner, data, and oversight description
  • Checklist view with evidence attachments
  • Trust metrics over time
  • Incident log and follow-up actions

Key UX elements

  • Risk badges
  • Blocked-until-complete checklist
  • Evidence links
  • Quarterly review reminders
  • Export for audit

10

Governance framework principles

Governance framework principles
PrincipleWhat it means in practice
Human oversightA named person can stop or override the system
TransparencyUsers are told when AI is involved and what it does
Data protectionLawful basis, minimization, and retention are documented
FairnessBias testing on the groups the system affects
AccountabilityOne owner per system, recorded in the inventory
SecurityAccess control, secrets handling, and logging
SustainabilityModel and infrastructure cost and energy considered
AuditabilityDecisions and overrides are reconstructable

R1

Risk Analysis

Risk matrix
RiskImpactMitigation
Shadow AI outside the inventoryHighDiscovery sweeps, easy registration, procurement gate
Checklist becomes theatreMediumEvidence required per item, sampling audits
Incorrect AI Act classificationHighDocumented reasoning, legal review, periodic reassessment
Stale data in the dashboardMediumQuarterly owner review with reminders

R2

Implementation Roadmap

  1. Weeks 1–2

    Phase 1: Framework

    • Risk levels
    • Checklist definition
    • Roles and accountability map
  2. Weeks 3–4

    Phase 2: Prototype

    • Inventory and detail views
    • Checklist flow
    • Incident log
  3. Months 2–3

    Phase 3: Pilot

    • Register existing systems
    • Run first quarterly review
    • Report to management

R3

Change Management

  • Owner onboarding sessions
  • Lightweight registration so compliance is easier than avoidance
  • Quarterly governance review in the management agenda
  • Clear escalation path for employees

R4

Success Metrics

Coverage

  • Share of AI systems registered
  • Share with a named owner
  • Share with completed checklist

Compliance

  • AI Act classifications completed
  • GDPR reviews completed
  • Open incidents older than 30 days

Trust

  • Trust survey score
  • User complaints
  • Explanation requests

R5

Deliverables

  • Dashboard concept
  • Risk framework
  • UI prototype
  • Governance checklist
  • Case study

Responsible AI requires governance, transparency, and accountability.

Next project

AI Readiness Audit & Transformation Roadmap

View Case Study