Ethics and Governance of Emerging Technology in Practice: An Advanced Technical Guide

Inside the three procedures that actually decide whether an emerging technology deploys: the fundamental-rights impact assessment, the institutional review board, and the regulatory sandbox.

Before the vote: an ethics review board's table set for a protocol hearing, binders open to their first flagged page. — Image prompt and art direction by Brecht Corbeel; image generated to that direction.

Abstract

Ethics principles do not, by themselves, stop a system from shipping or admit a protocol into a hospital. Three procedures do that work: a fundamental rights impact assessment under the EU AI Act's Article 27, an institutional review board applying 45 CFR 46 and the Belmont Report's three principles, and a regulatory sandbox of the kind the UK's FCA pioneered. This guide walks through all three as they are actually operated, with the forms, statutes, and institutional roles that make each a working mechanism, separating verified procedural fact from analysis of where each succeeds or fails.

Three rooms where governance actually happens

Write “AI ethics” into a search box and the answer comes back as a list of principles: fairness, transparency, accountability, human oversight, respect for human dignity. The Universal Declaration of Human Rights and UNESCO’s 2021 Recommendation on the Ethics of Artificial Intelligence both operate at this level, and they matter — the UNESCO Recommendation was adopted by all 193 member states at the General Conference’s 41st session on 23 November 2021, making it the first global standard-setting instrument on AI ethics [10]. But a principle does not, by itself, stop a system from being switched on, admit or refuse a research protocol, or tell a regulator what a firm may test on real customers next month. Three procedures do that work, and this guide is a walkthrough of how each one is actually run: the algorithmic or fundamental-rights impact assessment required before a public body deploys a high-risk system, the institutional review board that approves or rejects a human-subjects research protocol, and the regulatory sandbox that lets a bounded real deployment run under direct supervision. Fact, vendor claim, analysis and prediction are marked apart throughout; where a claim is this author’s judgment rather than a cited finding, it is flagged as analysis.

Part one: conducting a fundamental rights impact assessment

The statutory trigger

Article 27 of the EU AI Act (Regulation 2024/1689) obliges specific deployers — public-law bodies, private entities providing public services, and deployers of certain high-risk systems under Annex III points 5(b) and 5©, largely creditworthiness and insurance-risk systems — to perform a Fundamental Rights Impact Assessment (FRIA) before putting a high-risk AI system into use [1]. This is a narrower population than “every AI deployer in the EU”: providers of high-risk systems have their own, fully harmonized obligations elsewhere in the Act; the FRIA duty sits specifically on deployers, and functions as a minimum-harmonization floor, meaning individual member states may legislate a stricter version but not a weaker one [2]. The obligation takes effect on 2 August 2026 [2] — a date that, as this guide is written, has already arrived, so any covered deployer without a completed FRIA on file is presently out of compliance, a fact worth stating plainly rather than treating as a future milestone.

What the assessment actually asks

Article 27 specifies the assessment’s contents rather than leaving them to each deployer’s discretion. A FRIA must describe: the deployer’s own processes in which the system will be used, consistent with its intended purpose; the period and frequency of each intended use; the categories of natural persons and groups likely to be affected in the specific context of use; the specific risks of harm likely to affect those groups; a description of the implementation of human oversight measures according to the instructions of use; and the measures to be taken in case those risks materialise, including internal governance and complaint mechanisms [1] [2]. Read as a working document rather than a legal abstraction, this is a form with six load-bearing sections, and the section that most often gets written thin in practice — the specific, differentiated risk to specific affected groups, as opposed to a generic “may impact fairness” boilerplate line — is exactly the section a supervisory authority is positioned to scrutinise once national market surveillance regimes stand up around the August 2026 deadline. Analysis: because the duty sits on the deployer rather than the system provider, an identical off-the-shelf model can trigger six different FRIA obligations across six different deploying bodies, each shaped by that specific body’s “specific context of use” — the same underlying model used for eligibility screening in one municipality and for fraud triage in another is not, under this framework, one assessment problem but two.

How it compares to an older cousin: Canada’s Algorithmic Impact Assessment

Canada’s federal Directive on Automated Decision-Making, in force since 2019 and periodically reviewed since, requires an Algorithmic Impact Assessment (AIA) before a federal institution deploys an automated decision system that falls within scope and affects the rights, privileges, or interests of individuals or businesses [8]. The AIA tool is a public, openly licensed questionnaire made of 65 risk questions and 41 mitigation questions; scoring against them classifies the system into one of four impact levels, and each level carries scaled obligations — peer review, public transparency about the system’s use, degrees of human-in-the-loop oversight, and ongoing monitoring [9]. Existing systems procured or developed before 24 June 2025 have until 24 June 2026 to bring their paperwork into line with the updated directive [9]. Compared to the EU’s FRIA, Canada’s AIA is older, narrower in scope (federal institutions only, not private deployers of public services), and more mechanical — a fixed-weight questionnaire that outputs a tier, rather than a narrative assessment of specific affected groups. Analysis: the questionnaire format buys consistency and auditability across hundreds of federal systems at the cost of the contextual specificity Article 27 asks for; a scored checklist is easier to game by answering defensively, and harder to game by omission, than a narrative document a deployer’s own legal team has to sign.

Doing the work: NIST’s four functions as a working method

Neither the EU nor Canadian statute specifies how to identify risk, only what the resulting document must contain. The NIST AI Risk Management Framework (AI RMF 1.0), published in January 2023, supplies the missing method as four functions applied iteratively across a system’s lifecycle: Govern, which establishes policy, accountability and oversight structures before anything else starts; Map, which establishes context, categorizes the system, and characterizes likely impacts, including from third-party components; Measure, which uses quantitative and qualitative techniques to analyze, benchmark and monitor the identified risks; and Manage, which allocates resources to the risks Map and Measure surfaced, in priority order [5]. In practice, a FRIA under Article 27 is what Map and Measure look like when their output is forced into a specific statutory template: the “categories of natural persons… likely to be affected” clause is Map’s context-and-impact-characterization step; the “specific risks of harm” clause is Measure’s benchmarking step; and the “measures to be taken… including internal governance” clause is Manage. Analysis: treating the NIST functions as the assessment’s internal methodology, and the Article 27 text as its external reporting format, resolves what otherwise looks like a conflict between a voluntary US framework and a mandatory EU one — they operate at different layers and were never actually competing for the same job.

Figure 1. A fundamental rights impact assessment worksheet, one risk-tier tab caught mid-turn before the affected-groups section is filled in. — Image prompt and art direction by Brecht Corbeel; generation pending.

Part two: running an ethics-review-board process for an emerging-technology protocol

The two founding principles a board actually applies

Every institutional review board (IRB) operating under U.S. federal regulation exists downstream of a single 1979 document. The Belmont Report, issued by the National Commission for the Protection of Human Subjects of Biomedical and Behavioral Research, sets out three principles — respect for persons, beneficence, and justice — as the ethical foundation for human- subjects research [4]. Respect for persons requires treating individuals as autonomous agents capable of deliberate self-determination, while extending protection to persons with diminished autonomy; beneficence requires both not harming and actively securing well-being, weighing possible benefits against possible harms; justice concerns fair distribution of the burdens and benefits of research, so that no group bears a disproportionate share of the risk for benefits that accrue elsewhere [4]. These three principles are not themselves law — they are translated into binding procedure by the Common Rule, codified at 45 CFR 46, which governs federally funded human-subjects research in the United States [3].

The approval criteria a board is actually voting on

When a protocol for an emerging technology — a novel neurotechnology trial, an AI-mediated diagnostic study, a wearable biosensor deployment — comes before a full IRB meeting, the board is not voting on whether the technology is good. It is voting against a specific checklist derived from 45 CFR 46’s approval criteria: whether risks to subjects are minimized through sound research design and by not exposing subjects to risks unnecessary given already-available data; whether risks are reasonable in relation to anticipated benefits and the importance of the knowledge expected; whether selection of subjects is equitable, considering the purposes of the research and the setting; whether informed consent will be sought from each prospective subject and appropriately documented; and, where applicable, whether the research plan makes adequate provision for monitoring data collected to ensure subject safety and adequate provisions to protect privacy and maintain confidentiality [3]. A board’s vote at the end of a meeting is formally binary at the protocol level — approved, approved with required modifications, or disapproved — but arrives after each criterion has effectively been scored separately by the reviewing members, with the informed-consent documentation and the risk-minimization design typically drawing the most substantive discussion for a genuinely novel technology, since neither the subjects nor, often, the board itself has prior experience calibrating what “reasonable risk” means for it. Analysis: this is the mechanism’s real strength and its real limit at once — a board composed of members experienced with conventional biomedical or behavioral protocols is applying well-worn judgment to risk categories (physical harm, breach of confidentiality, coercion) that a genuinely novel technology may not map onto cleanly, which is why federal guidance increasingly recommends adding members with specific technical expertise for emerging-technology protocols, even though 45 CFR 46 itself does not mandate a technology-specific composition requirement.

Where the emerging-technology case actually differs procedurally

Two things regularly change for an emerging-technology protocol relative to a routine biomedical one, in practice rather than by separate statute. First, board composition: 45 CFR 46 requires diversity of expertise sufficient to review the specific research being proposed, which for a genuinely novel technology means a board that lacks a member competent to evaluate the technology’s specific risk profile is expected to consult an outside expert before voting, not simply proceed with generalist judgment. Second, the consent document itself becomes the site of the hardest drafting work, because respect for persons under Belmont requires that consent be informed by an accurate account of risk, and for an emerging technology the actual risk profile is frequently uncharacterized rather than merely unlikely — the honest answer to “what happens if this goes wrong” is sometimes “we do not fully know,” and a consent form that omits that admission fails the principle even if it recites every known risk correctly. Analysis: this is the procedural pressure point where “ethics board as gatekeeper” and “ethics board as knowledge-production body” pull against each other — a board asked to approve a protocol precisely because the technology is new is being asked to bless the search for facts it does not yet have, using a consent architecture built for research where the risk taxonomy is already settled.

Figure 2. An IRB protocol shelf mid-retrieval, one binder half out of its slot on the way to a full-board meeting. — Image prompt and art direction by Brecht Corbeel; image generated to that direction.

Figure 4. A statute redline session: a margin note's pen stroke caught mid-line before the clause is finalized. — Image prompt and art direction by Brecht Corbeel; image generated to that direction.

Part three: how a regulatory sandbox is actually structured and operated

The FCA model, as it actually runs

The UK Financial Conduct Authority’s regulatory sandbox, the most-copied design internationally, lets an authorised firm, a firm seeking authorisation, or an unauthorised technology business test an innovative product or service on a small scale, with real consumers, inside defined safeguards [7]. An applicant answers a structured set of questions about how its proposal meets published eligibility criteria and about the specifics of its testing plan; meeting all criteria is required to be accepted, not merely helpful [6]. If accepted, the firm is assigned a dedicated case officer as its point of contact for the duration of the test, and is given roughly four weeks to work with that officer to finalise test activities against the testing plan and to obtain whatever specific regulatory tool — a waiver, individual guidance, a modified rule — the test actually needs before live testing starts [6]. Live testing itself typically runs around six months, in line with the agreed plan, though the FCA states timelines can vary with the use case’s nature and complexity [6]. The FCA ran the sandbox as fixed enrollment cohorts through 2021 and has since moved to rolling applications, while retaining the cohort label for purpose-built groupings — cohort 6 opened for general applications, and a dedicated cohort was opened in November 2025 specifically for firms issuing stablecoins [7]. Fact, not vendor claim: the case-officer assignment and the fixed roughly-six-month test window are procedural commitments stated on the regulator’s own site, not marketing language from a sandbox participant.

What a sandbox is actually for, mechanically

A regulatory sandbox is not a subsidy or a marketing exemption; it is an information-generating device. A regulator ordinarily writes rules ahead of a technology’s deployment, working from submissions, forecasts and analogy to existing rules. A sandbox inverts the order for a bounded population: a real but limited deployment runs first, under direct case-officer supervision and against an agreed testing plan, and the regulator observes what actually happens to real customers under real market conditions before deciding whether and how to write a permanent rule for the wider market [6]. The bound that makes this safe to run is the “small scale” condition combined with continuous supervision — the exposure a sandbox firm can create is capped by its cohort’s testing plan, not merely by good intentions, and the case officer’s role includes intervening if the test drifts from that plan. Analysis: this is precisely why sandboxes have spread to non-financial regulators for emerging technology generally (healthtech, energy, and several jurisdictions’ AI-specific proposals draw directly on the FCA design) — the mechanism generalizes to any domain where the central governance problem is that regulators must write ex ante rules for a technology whose real failure modes only surface under live use, and a sandbox lets that discovery happen inside a fence rather than across an entire market at once.

The exit, which is where a sandbox’s actual output lives

The test period is not the sandbox’s product; the exit report is. At the end of the agreed testing period, the firm and its case officer produce an account of what the test showed against the plan’s original hypotheses, including where the product performed as expected, where it did not, and what consumer-facing issues arose. This exit document — not the fact that testing occurred — is what feeds back into whether a regulator authorises the firm for wider-market operation, requires further modification, or declines to proceed. Analysis: a sandbox that is evaluated only by “did the cohort complete testing” rather than by the substance of exit reports across cohorts is not actually functioning as an evidence-generation mechanism, it is functioning as a subsidized pilot program with an evidentiary label attached; distinguishing the two requires checking whether a regulator has published or cited a body of individual exit findings in later general rulemaking, which is a stronger test of the mechanism’s real function than counting how many firms passed through it.

Figure 3. A regulatory sandbox test bench: a prototype running live inside its glass enclosure, one monitoring cable still being seated. — Image prompt and art direction by Brecht Corbeel; image generated to that direction.

Figure 5. A sandbox cohort tracking board, one firm's case tile sliding from 'testing' toward 'exit report' mid-move. — Image prompt and art direction by Brecht Corbeel; image generated to that direction.

Where the three mechanisms actually meet, and where they do not

These three procedures answer different questions and were built for different failure modes, and treating them as interchangeable “ethics review” misreads all three. A FRIA is a documentation-and-disclosure obligation attached to a specific deployment by a specific deployer, enforced (once national supervisory bodies stand up around the compliance date) after the fact against a filed record [1]. An IRB is a prior- restraint gate: a protocol without approval simply may not proceed, and the board’s judgment is dispositive rather than advisory [3]. A regulatory sandbox is neither a filing requirement nor a gate in the IRB sense; it is a supervised trial whose entire purpose is generating evidence a regulator did not have before, under conditions bounded enough that a bad outcome stays contained [6].

Analysis, stated as such: the common thread across all three, despite the very different legal architecture, is that each substitutes a specific, falsifiable procedural question — who is affected and what happens if this errs; does risk-minimization and informed consent meet a stated criterion; what did a bounded real trial actually show — for the unfalsifiable question “is this technology ethical,” which no procedure can actually adjudicate. That substitution is this guide’s central practical claim, and it is testable against experience going forward: if FRIA filings, IRB minutes, and sandbox exit reports increasingly become boilerplate documents that recite the statutory categories without engaging the specific technology’s actual risk profile, that is observable evidence the substitution has failed in practice, regardless of how well-designed each procedure looks on paper.

A scenario, and its disconfirmation condition

Scenario, explicitly labeled, horizon to 2030: assume EU member-state supervisory authorities begin publishing aggregate FRIA findings the way the FCA publishes aggregate sandbox outcomes, and that a comparable evidentiary culture develops around Article 27 filings. Under that assumption, a plausible five-year outcome is that FRIA quality converges toward sandbox-style specificity, because deployers learn that a thin, boilerplate FRIA becomes visible as such once aggregate publication makes comparison possible. Assumptions: this depends on supervisory authorities actually choosing to publish or cite aggregate findings, which Article 27 does not itself require. Observable indicator: the emergence, or non-emergence, of any EU member-state supervisory body publishing cross-deployer FRIA findings or citing them in subsequent guidance within the next three years. Disconfirmation condition: if by 2030 no supervisory authority has published such aggregate findings and FRIAs remain filed but unreviewed records, the scenario should be treated as not having materialized, and the mechanism’s evidentiary promise as unfulfilled regardless of the statute’s formal existence.

Conclusion

None of these three procedures is a substitute for the human-rights instruments that state what is at stake — the Universal Declaration’s account of the person, UNESCO’s account of AI’s obligations toward human dignity [11] [10]. What the FRIA, the IRB, and the sandbox each supply is a mechanism by which those commitments become something a specific deployer, board, or regulator must actually do, on a specific date, against a specific document, with a specific person accountable for the answer. That is the distance between an ethics principle and a governance procedure, and it is the distance this guide has tried to walk.

Sources

1. European Parliament and Council of the European Union. Article 27: Fundamental Rights Impact Assessment for High-Risk AI Systems. EU Artificial Intelligence Act (Regulation 2024/1689), artificialintelligenceact.eu (2024).
2. Eduardo Gill-Pedro. Fundamental Rights Impact Assessments in the EU's AI Act: A teleological and contextual analysis of the obligations of deployers. European Journal of Law and Technology (2024).
3. U.S. Department of Health and Human Services, Office for Human Research Protections. 45 CFR 46 — Protection of Human Subjects (the Common Rule). HHS.gov (2018).
4. National Commission for the Protection of Human Subjects of Biomedical and Behavioral Research. The Belmont Report: Ethical Principles and Guidelines for the Protection of Human Subjects of Research. U.S. Department of Health, Education, and Welfare / HHS.gov (1979).
5. National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST (2023). DOI: 10.6028/NIST.AI.100-1.
6. Financial Conduct Authority. Apply to the Regulatory Sandbox. FCA.org.uk (2026).
7. CMS Law-Now editorial staff. Applications to cohort 6 of the FCA's regulatory sandbox now open. CMS Law (2025).
8. Treasury Board of Canada Secretariat. Directive on Automated Decision-Making. Government of Canada, tbs-sct.canada.ca (2023).
9. Government of Canada. Algorithmic Impact Assessment tool. Canada.ca (2025).
10. UNESCO General Conference, 41st session. Recommendation on the Ethics of Artificial Intelligence. UNESCO (2021).
11. United Nations General Assembly. Universal Declaration of Human Rights. United Nations (1948).

Originally published at https://absolutedigitalpublishers.com/articles/ethics-and-governance-of-emerging-technology-in-practice-an-advanced-technical-guide.