Create one reliable view of third party risk and the work needed to resolve it.
02 / Vendor Management / Sprinto
Designing an AI assisted
compliance inventory.
A Vendor Management experience that connects AI assisted discovery with risk, ownership, due diligence, people, staff devices and reporting.
- My role
- Product Designer
- My contribution
- Vendor discovery, risk classification, due diligence, monitoring, people, staff devices and reporting workflows.
- Project context
- Professional experience · Vendor Management system
Overview
Help growing teams understand what they use, who owns it and where risk needs attention.
I was responsible for the Vendor Management experience at Sprinto. The work covered discovery, risk classification, due diligence, monitoring and reporting, while connecting vendors to the people and staff devices around them.
The goal was not to place more information on a dashboard. It was to turn scattered compliance signals into a clear sequence of decisions.
Research synthesis, information architecture, user flows, interaction design and handoff with product and engineering.
Use automation to surface possible gaps without presenting an AI suggestion as a confirmed fact.
The public case study uses representative visuals and sanitized examples. It communicates my design approach without revealing customer or production data.
The problem
The information existed, but the relationships between it were easy to lose.
Compliance owners were working across vendor records, people, devices, assessments and reports. A dashboard could show totals, but it did not always explain which item needed attention, why it mattered or who should act next.
As a company grew, manually maintained vendor lists could also miss tools already being used by employees. That created a difficult starting point: teams could not assess a risk they did not know existed.
Unknown inventory
Unrecorded services could sit outside the formal vendor review process.
Scattered context
Risk, ownership, evidence and due diligence status were difficult to read together.
Weak prioritisation
Counts showed volume, but not always the next decision or the consequence of waiting.
Manual reporting
Preparing a review meant collecting information from several parts of the product.
Research and synthesis
I followed the decisions behind the dashboard.
I combined workflow mapping, stakeholder conversations, product walkthroughs and recurring support themes. The goal was to understand how a possible signal becomes a trusted compliance record, and where context is lost between teams.
Trace discovery, confirmation, assessment, evidence and reporting.
Separate the decisions owned by compliance teams and vendor owners.
Identify where status, ownership and evidence become disconnected.
Clarify where AI can suggest and where a person must decide.
“I cannot assess a service if I do not know the team is using it.”
Teams scan for what is incomplete before they look at the overall score.
An automated signal is a starting point, not a confirmed vendor record.
Source, owner, risk and evidence need to remain connected.
Ask a compliance owner to add, dismiss or assign every suggestion.
Pair each state with the reason, responsible person and next step.
Visibility before scoring
The first problem was not calculating risk. It was knowing every service, person and device that belonged in scope.
Status needs a reason
A warning becomes useful only when the interface explains what triggered it and what action can resolve it.
Automation needs boundaries
AI could surface possible gaps and review evidence, while confirmation and final risk decisions remained visible human actions.
Discover
A new service appears
Is this a real vendor?Confirm
Check source and usage
Who can verify it?Assess
Classify access and impact
Why is this risk level?Collect
Request and review evidence
What is still missing?Report
Share readiness and exposure
Can I trace the result?Design questionHow might we help a compliance owner move from a possible risk to a defensible decision without asking them to reconstruct the context?
Product direction
Treat vendors, people, devices and reports as one connected inventory.
The system needed a shared model so users could move from a risk summary into the exact vendor, person, device or evidence record behind it.
Vendors
Discover services, classify risk, complete due diligence and monitor incidents.
People
Understand ownership, access and the employees connected to each service.
Staff devices
Surface device posture and unresolved checks that affect readiness.
Reports
Turn the inventory into evidence that teams can review and share.

AI assisted discovery
Surface what the team may have missed, then explain why it appeared.
Connected sign in activity can reveal services that employees already use. Instead of adding every signal to the vendor register automatically, the experience presents a possible vendor for review, shows the discovery source and keeps the compliance owner in control of confirmation.
- 01Detect
Find a possible vendor, person or device from connected systems.
- 02Explain
Show the source and the reason the record was suggested.
- 03Confirm
Let a person add, dismiss or assign the record before assessment begins.
Design response
Turn every status into a clear next step.
A risk label alone is not enough. The interface connects each signal with its source, owner, due diligence state and available action.
Vendor risk model
Move from a scheduled review to a risk score the team can understand.
The assessment experience connects the current evidence task with the rules behind the score. Compliance teams can see what is due, configure the factors that matter to their organisation and inspect how each answer changes the final risk level.
Designing for responsibility
One inventory.
Different decisions.
The same record needs to answer a different question for each person involved.
Where are the gaps?
Prioritise unreviewed vendors, incomplete assessments and open evidence requests.
What do I need to provide?
Keep the request, due date and supporting context together.
What requires attention now?
Summarise exposure and progress while preserving a path to the underlying record.
People and staff devices
Connect employee readiness to the record behind it.
People compliance is more useful when a failed check leads to the exact person, missing requirement and available action. The flow moves from the staff inventory into onboarding prerequisites, then into a detailed record that brings training, policy acknowledgement, device reporting and verification together.
Evidence and reporting
Make the system explain its conclusion.
AI can help surface a vendor or pattern, but a compliance decision still needs traceable evidence. The design keeps source, ownership, review status and history visible so teams can understand what supports a result.
- Show where a discovery originated.
- Separate suggested records from confirmed records.
- Connect each risk to its assessment and evidence.
- Let every report lead back to the underlying record.
Continuous monitoring
Keep compliance useful after the first assessment.
A vendor can change after approval. Monitoring brings new findings back into the same ownership and remediation model, so teams can see what changed, understand the recommended response and return to evidence when the issue is resolved.
Separate passing resources from the few items that need attention.
Explain the recommended sequence without hiding the underlying evidence.
Keep the responsible person and due date beside the remediation work.
Outcome
A clearer operating model for compliance work.
The resulting direction joined discovery, review, ownership and reporting into one understandable system. It gave each role a more focused starting point while preserving the evidence needed to explain a decision.
Vendor records depended heavily on a manually maintained inventory.
AfterAI assisted discovery surfaced possible gaps for human confirmation.
Risk status and responsibility were read in separate contexts.
AfterSource, owner, assessment state and next action appeared together.
Reports summarised progress without always exposing the supporting record.
AfterSummary views retained a path back to evidence and activity history.
Automation earns trust when people can inspect it.
The important design question was not whether AI could find more signals. It was whether the product could explain a suggestion clearly enough for a person to judge it. That principle shaped the discovery states, the confirmation step and the way evidence remained connected throughout the workflow.
See what needs attention
Review risk, inventory and incomplete due diligence in one overview.
Business impact
Connect the design decision to a measurable business result.
Give compliance teams a more complete inventory and a clearer path to risk review, reducing manual follow up and audit preparation effort.
Earlier discovery of untracked vendors and staff devices
Shorter vendor review and evidence collection cycles
Lower exposure from overdue or unowned risks
Measuring after release
Signals I would track with product, data and engineering.
These are success measures for post launch evaluation, not claimed results.
- Inventory coverage
- Share of discovered vendors reviewed and assigned an owner
- Review cycle
- Median time from discovery to a completed risk decision
- AI usefulness
- Share of AI suggestions accepted, edited or rejected
- Audit effort
- Hours spent preparing vendor evidence and reports
Combine review hours saved with avoided audit preparation effort and the expected cost of unresolved vendor risk.
Final reflection
Let AI surface the question. Keep the decision human.
The product direction connected automated discovery with ownership, evidence and review, so compliance teams could act without losing the reasoning behind a result.


