Inspiration
Companies often respond to regulation by creating more policies, checklists and documentation.
But the real problem is frequently not the absence of documents. It is the absence of traceability.
A requirement may appear in one source, implementation evidence in another, and a contradictory public claim somewhere else. Product, engineering, legal and compliance teams can all believe that an issue belongs to somebody else.
The result is familiar:
- obligations without mapped evidence;
- internal plans without implementation proof;
- public claims that do not match operational documentation;
- unclear ownership;
- gaps that remain invisible until an audit or incident.
The inspiration for this project came from a simple observation:
Most organisations do not only need more documentation. They need to understand what their existing documentation actually demonstrates.
That led to our central principle:
Compliance is not a checkbox. It is an evidence trail.
What it does
AI Compliance Evidence Mapper is an evidence-readiness tool for developers, product teams, compliance professionals, legal operations and internal reviewers.
The current MVP focuses deliberately on one narrow workflow:
EU AI Act — Article 50 Transparency Readiness Demo
The user reviews:
- applicability assumptions;
- an AI system description;
- technical and product documentation;
- a user-facing disclosure.
The engine maps those materials to a small, prepared and versioned control set.
For every control, it can surface:
- evidence found;
- partial evidence;
- evidence not found in the supplied materials;
- conflicting evidence;
- applicability questions;
- human-review requirements;
- exact source excerpts and line numbers;
- evidence strength and limitations;
- a suggested responsible owner;
- the smallest useful next action.
It does not issue a legal verdict.
A missing document is not proof of non-compliance, and evidence coverage is not a compliance score.
The demonstration
The prototype uses a fictional organisation called LuminaDesk AI.
LuminaDesk is described as a generative workplace assistant that interacts directly with users and produces text.
Its prepared organisational materials contain several realistic evidence-readiness problems:
- internal plans mention an AI interaction disclosure, but the supplied materials do not demonstrate what the user sees;
- internal provenance metadata exists, but the documentation does not demonstrate an effective interoperable marking mechanism;
- the public description says that all answers are verified;
- internal documentation warns that the system may produce inaccurate information;
- the organisation’s provider or deployer role has not been documented;
- human-review claims lack a complete operational workflow.
The mapper does not conclude that LuminaDesk is violating the AI Act.
Instead, it says:
The supplied materials do not yet demonstrate this control.
It then connects that gap to an owner and a verification step.
Two evidence states
The prototype contains two editable scenarios.
Demo A — Evidence gaps
The first scenario contains supporting evidence, partial evidence, missing evidence, a cross-document conflict and unresolved applicability questions.
Demo B — Improved documentation
The second scenario adds:
- explicit disclosure evidence;
- documented disclosure timing;
- an implementation test;
- aligned public wording;
- a documented human-review workflow.
The evidence map improves, but the system still does not claim certification or legal compliance. Applicability and interpretation remain open for qualified human review.
This comparison demonstrates an important distinction:
Better evidence makes a claim more inspectable. It does not automatically make it legally correct.
Evidence Blueprint
The interface presents compliance evidence as a traceable workflow:
Source document
↓
Exact evidence
↓
Prepared control
↓
Responsible owner
↓
Next action
Users can inspect the connection between:
organisational sources;
exact excerpts;
selected transparency controls;
Product, Engineering, Compliance or Operations;
concrete next steps.
The goal is not to create another checklist. It is to expose the foundation beneath each organisational claim.
Prepared control model
The MVP includes selected evidence-readiness controls associated with:
AI interaction disclosure;
machine-readable marking of generated output;
clear and timely transparency information;
consistency between public and internal descriptions;
provider and deployer role assessment;
evidence supporting human-review claims.
The product distinguishes among:
selected regulatory controls;
internal evidence-quality controls;
applicability questions.
It does not present every control as a direct statutory obligation.
Official sources remain authoritative:
European Commission — AI Act overview
Regulation (EU) 2024/1689
European Commission — Article 50 transparency guidance
European Commission — Article 50 FAQ
According to current European Commission materials, the selected Article 50 transparency obligations apply from 2 August 2026.
The demo does not implement the complete Article 50 framework, and it is not legal advice or certification.
How we built it
We built the prototype as a standalone React and TypeScript application.
Its deterministic local engine:
parses editable documents into line-addressable evidence;
evaluates a prepared versioned control set;
deduplicates evidence;
preserves exact excerpts;
classifies evidence strength;
detects a prepared cross-document conflict;
produces applicability questions;
routes gaps to suggested owners;
creates deterministic next actions;
calculates transparent evidence-coverage metrics.
The business logic is separated from the React interface and can be tested independently.
The application uses:
no accounts;
no database;
no API keys;
no runtime AI calls;
no external legal-data service;
no private organisational data.
This makes every prepared result reproducible and inspectable.
How we used GPT-5.6
GPT-5.6 helped us transform a broad idea of regulatory analysis into a focused product.
We used it to:
identify evidence mapping as the narrow MVP;
distinguish evidence readiness from legal compliance;
design the control–evidence–gap–owner–action architecture;
define cautious status language;
develop the fictional LuminaDesk scenario;
structure the applicability workflow;
connect findings with cross-functional ownership;
establish legal, product and epistemic boundaries;
design the demonstration and interface hierarchy.
GPT-5.6 was used during product development. The submitted prototype does not make runtime model calls.
How we used Codex
Codex accelerated the engineering workflow from an empty repository to a tested standalone implementation.
We used Codex to:
scaffold and implement the React and TypeScript application;
build the deterministic evidence-mapping engine;
implement the versioned control model;
preserve exact source references and line numbers;
implement evidence-strength classification;
create cross-document conflict detection;
build applicability and owner-routing workflows;
generate deterministic next actions;
add meaningful engine and interface tests;
improve accessibility and responsive behavior;
verify linting and the production build;
document key product and engineering decisions;
distinguish prior work from the Build Week contribution.
Final product, architecture, regulatory-boundary and design decisions remained human-led.
Build Week contribution
Before Build Week
Our earlier AI Review Engine work already explored:
comparing requests, documentation and AI responses;
detecting missing requirements;
identifying documentation conflicts;
surfacing unsupported claims;
preserving evidence trails;
treating findings as verification leads rather than verdicts.
This project does not attribute those earlier mechanisms to Build Week.
Built during Build Week
The new contribution includes:
AI Compliance Evidence Mapper as a standalone product;
the selected Article 50 transparency-readiness demo;
a versioned control model;
an applicability questionnaire;
separation of regulatory controls, internal controls and scope questions;
evidence-to-control mapping;
evidence-strength classification;
exact source references;
cross-document conflict handling;
suggested-owner routing;
deterministic next-action planning;
transparent evidence-coverage metrics;
two prepared organisational evidence states;
official source metadata;
explicit legal and epistemic boundaries;
an accessible responsive interface;
automated tests and documentation.
Challenges we faced
Avoiding the compliance-verdict trap
A conventional dashboard naturally pushes the design toward red and green status indicators. But “evidence not found” is not equivalent to “requirement violated.”
We had to design both the engine and interface around evidence conditions instead of pass/fail conclusions.
Separating evidence from applicability
Before evaluating evidence, a team may need to establish its role, system context, territory and relevant exceptions.
The prototype therefore preserves applicability questions rather than silently converting assumptions into legal conclusions.
Handling partial evidence
Internal provenance metadata may support traceability, but it does not automatically demonstrate an effective interoperable marking mechanism.
The engine needed to represent this as partial evidence without discarding it or overstating its significance.
Preserving exact traceability
A finding is only useful if a reviewer can return to its source. Every evidence connection therefore retains the document, line number, exact excerpt, explanation and limitation.
Turning gaps into work
A list of problems is not an operational plan. Each finding needed to connect to a likely owner and the smallest useful next verification step.
What we learned
We learned that compliance-readiness tools should not begin by asking:
Are we compliant?
They should begin with more inspectable questions:
What claim are we making?
Which evidence supports it?
Where is that evidence located?
Do our documents tell the same story?
What remains unknown?
Who should investigate it next?
We also learned that uncertainty should be represented as structured information—not hidden behind a confident score.
A careful “needs specialist review” can be more valuable than a misleading percentage.
What's next
The current prototype intentionally focuses on one narrow transparency-readiness workflow.
Future versions could support separately maintained adapters for:
additional EU AI Act workflows;
internal AI governance policies;
vendor due diligence;
ISO/IEC 42001 evidence;
DORA;
NIS2;
customer contractual requirements.
The long-term architecture remains the same:
Obligation
↓
Evidence
↓
Gap
↓
Owner
↓
Action
The goal is not to replace legal, compliance or engineering professionals.
It is to help them see the same evidence.
Log in or sign up for Devpost to join the conversation.