At a glance
A SaaS platform built to help large organisations assess and manage their AI regulatory risk exposure came to Data Ethica with a specific challenge: the product was being designed to guide clients through complex compliance frameworks, and it had to do so without itself becoming a source of confusion, false assurance, or misplaced trust. The ethical stakes of the tool were inseparable from its product design. Ethics by design here was not a layer added afterwards. It was the architecture.
The engagement focused on the ethics posture of the platform itself: how it classifies risk, how it surfaces results, how it handles multi-organisation data, how it presents its outputs, and where it must draw a clear line between what the tool does and what it cannot claim to do. The result was a set of design principles and concrete implementation choices embedded at the structural level of the product.
1. Why AI compliance tools carry their own ethical stakes
A platform that helps organisations assess their AI systems for legal risk is itself an AI system. That circularity is not a curiosity: it is a genuine design problem. The platform classifies, scores, and generates recommendations. Each of those functions carries ethical weight.
Three specific risks defined the brief:
- False assurance. A compliance score that looks authoritative can lead an organisation to believe it is compliant when it has only self-reported that it is. If the design does not make this distinction structurally visible, the tool becomes a liability instead of an asset.
- Opaque classification. Placing an AI system into a regulatory risk tier without explaining which inputs drove that classification undermines the right of the user to understand, contest, and act on the result. Opacity in a tool designed to promote transparency is a contradiction that clients will eventually encounter in front of a regulator.
- Data isolation failure. Large organisations operating multiple brands, subsidiaries, or territories have a reasonable expectation that one unit cannot see the compliance posture of another. A multi-tenant architecture that does not enforce strict data containment at the model level creates both a privacy risk and a competitive one.
These were not hypothetical concerns. They were the conditions under which the platform would be deployed and the conditions under which its clients would be audited.
2. The brief
The platform builder engaged Data Ethica at an early stage of product design, before the core assessment engine and scoring logic were finalised. The objective was to review the architecture through an ethics by design lens and produce a set of concrete requirements that the engineering team could act on directly.
The brief had two distinct layers:
- Identify the points in the product where design choices create ethical risk: where results could be misread, where data could bleed across organisational boundaries, where the platform could overstate its authority.
- Translate each identified risk into a specific design requirement: not a general principle, but an actionable constraint that would change how a particular feature was built.
The engagement was deliberately scoped to the product design layer. It was not a compliance audit of the platform’s own regulatory position, and it was not a review of the legal frameworks the platform covers. Those questions were for the platform’s own legal counsel. The ethics by design question was narrower and harder: given that this product will be used by people making consequential compliance decisions, what must its design make impossible to misunderstand?
3. Ethics by design choices embedded in the platform
Six design decisions shaped the product’s ethical architecture. Each one responded to a specific failure mode identified in the brief.
The platform classifies AI systems into regulatory risk tiers based on a structured triage process. The design requirement was that every classification result must surface which inputs drove the outcome, with references to the specific regulatory articles they map to. A result that says “High Risk” without showing which answer patterns triggered that tier is not actionable and not auditable. The classification logic is visible to the user, not abstracted behind a score.
The platform generates recommendations and remediation actions based on assessment answers. The design requirement was that none of these actions should be applied automatically. Every suggestion must go through an explicit confirm or dismiss step. The distinction matters: an action plan that a user has confirmed is one they own. An action plan that appeared without their input is one they may not understand, may not be able to defend, and may not be able to contest. Advisory outputs require deliberate acceptance to become active.
Self-reported compliance answers carry limited evidentiary weight without supporting documentation. The design requirement was that every answer in the assessment engine must support attachment of evidence: a document, a note, a reference. Evidence linkage transforms a self-assessment from a statement of intent into a documented record. It also changes the internal dynamic: teams that know their answers can be challenged will answer differently than teams that believe no one will look.
Compliance decisions must be traceable. When an organisation revises an assessment answer, the previous answer must be preserved, not overwritten. The design requirement was a soft delete model throughout: no record is ever hard deleted, every change creates a new version, and the complete history of every assessment decision is recoverable. This is simultaneously a GDPR access rights requirement, a regulatory audit requirement, and a product integrity requirement. A compliance platform that loses its own history is not a compliance platform.
The platform serves large organisations with multiple brands and territories. The design requirement was strict containment: a user operating at one brand or regional level must have no visibility into peer organisations at the same level, and must be unable to infer the compliance posture of a sibling entity even through aggregate scores. Data isolation was enforced at the data model level, not as a UI restriction layered on top of shared data. The distinction matters because UI restrictions can be bypassed; data model constraints cannot.
The hardest design decision was also the most important. The platform produces compliance scores. Those scores will be read by compliance officers, presented to boards, and potentially shown to regulators. The design requirement was that the platform’s outputs must carry explicit, structurally embedded disclaimers at every point of use: scores reflect self-reported assessments, not verified compliance; the platform does not provide legal advice; the platform does not perform or replace conformity assessments required under Article 43 of the EU AI Act. These disclaimers are not a legal footnote buried in the terms of service. They are visible elements of the user interface, present at the moment the score is read.
The hardest tension in the product design was this: the platform must be useful enough that organisations trust it, and honest enough that they do not trust it too much. That balance is not a communications problem. It is a design problem. It has to be solved in the interface, not in the documentation.
4. The central ethical tension: scoring without certifying
Every AI compliance platform faces a version of the same structural problem. It produces a number. That number represents the aggregate of self-reported answers weighted by a scoring methodology. It does not represent a verified compliance state. It does not mean an organisation has passed any test. It cannot be used as a defence against regulatory enforcement.
But organisations will try to use it that way. A high score is reassuring. Reassurance reduces the urgency of further action. Reduced urgency increases actual risk. The platform, designed to reduce legal exposure, can inadvertently increase it.
The design response to this tension was threefold:
- Every score display includes a contextual label making its self assessed nature explicit, at the point of reading, not in a separate help section.
- The scoring methodology is documented and available to users: they can see how weights are applied, which answer patterns contribute to which outcome, and why the system amplifies risk for higher regulatory tiers.
- The action plan generated by the platform is framed as a preparation tool for conformity assessment, not a substitute for it. The language is deliberate: “readiness” rather than “compliance”, “self-assessment” rather than “certification”.
This is ethics by design applied to language as much as to architecture. The words in the interface carry weight. They were chosen to reflect what the platform actually does, not what a user might hope it means.
5. Results: what the ethics by design posture delivers
| Design choice | Risk addressed | Operational benefit |
|---|---|---|
| Transparent classification | Opaque risk tier assignment with no basis visible to the user. | Users can act on the result, explain it internally, and contest it if wrong. |
| Confirm or dismiss advisory flow | Auto applied recommendations create obligations the user did not choose. | Action plans are owned, not imposed. Accountability rests with the right team. |
| Evidence linkage | Self reports with no supporting documentation are indefensible under audit. | Assessments become documented records that survive regulatory scrutiny. |
| Full audit trail | Compliance decisions are revised without trace, making history irrecoverable. | Full version history available for regulatory audit and internal review. |
| Data isolation | Multi entity platforms leak compliance posture across organisational boundaries. | Strict containment by design, not by permission setting. |
| Structural disclaimers | Scores read as certifications, creating false assurance and real exposure. | Platform outputs are understood as what they are: assessed readiness, not verified compliance. |
The combined effect is a platform that can be shown to a regulator without embarrassment: its design reflects the same principles it helps clients demonstrate. That coherence is not a coincidence. It is a direct consequence of building ethics in rather than bolting it on.
6. Why AI compliance tools must lead by example
There is a particular responsibility that comes with building tools in the compliance and ethics space. Organisations use these platforms to demonstrate their own responsible AI posture. If the tool they use to do that is itself opaque, overreaching, or poorly governed, the demonstration is undermined before it begins.
Three principles apply to any platform in this space:
- The tool is not above the standard it enforces. A platform that helps organisations demonstrate transparency under the EU AI Act must itself be transparent about how it classifies, scores, and recommends. Exempting the tool from the logic it enforces is not a sustainable position.
- Usefulness and honesty are not in tension. The concern that honest disclaimers will undermine client confidence in the platform is a design problem, not a communications problem. A well designed product can be genuinely useful and genuinely honest at the same time. The design challenge is making both visible simultaneously, not trading one for the other.
- Ethics by design is a product differentiator in regulated markets. As the EU AI Act enforcement machinery becomes operational, clients will scrutinise the tools they use for compliance management. A platform that has embedded ethics by design from the architecture up is better placed to survive that scrutiny than one that manages ethics as a policy document sitting outside the codebase.
The question for any AI compliance platform is not whether to claim ethical design. Every product in this space will make that claim. The question is whether the design itself makes the claim credible: whether someone who reads the source code, the data model, and the interface copy would reach the same conclusion as someone who reads the marketing page. That coherence is what ethics by design actually means.
EU Commission Independent Expert on AI, ODI-certified data ethicist, DPO, and lecturer at leading European business schools.