MODULE 5 · LESSON 2
Free — no login requiredSign in to track progress, save quiz attempts and enrol in the full course.
Sign in to track progress / enrolRisk Manager, Environmental Steward and Trust Builder
The remaining two roles, plus a topic that version 1.0.0 of the syllabus added specifically: the environmental impact of AI use.
Risk and compliance manager
The Requirements Engineer identifies and mitigates the legal, ethical and operational risks of AI use — from protecting personal data and avoiding bias through to ensuring outputs meet regulatory and contractual requirements.
The syllabus names three concrete duties:
- Choosing processing options, for example local versus cloud.
- Ensuring data minimisation.
- Detecting model drift.
Example from the syllabus: pseudonymising stakeholder feedback before uploading it to an AI service hosted outside the jurisdiction, and routinely checking whether the AI is still producing regulation-compliant suggestions.
That example is two responsibilities in one sentence, and they operate on different timescales. Pseudonymisation is a precaution taken before each upload. Routinely checking for continued compliance is monitoring on a schedule — the mitigation for model drift from module 4. A Requirements Engineer who does the first and not the second has protected the data and left the output quality unguarded.
Environmental impact of AI use
Generative AI has an environmental impact, primarily from the energy required to train and operate large models. Many of those factors lie beyond a Requirements Engineer's direct control — but the way AI is selected and used within the RE process can influence energy consumption.
The syllabus is direct about the consequence: unreflective or unnecessarily intensive use of AI tools introduces environmental, reputational and governance risks for projects and organisations.
Example from the syllabus: a project team plans to run an LLM continuously in the background to monitor and re-classify all requirements in real time. The Requirements Engineer identifies that this always-on pattern would consume significantly more energy than scheduled batch processing, with little additional benefit, and recommends batch processing instead — reducing environmental impact while still meeting the team's analytical needs.
The reasoning pattern in that example generalises well beyond energy. The question asked was: what does continuous processing buy us that periodic processing does not? When the honest answer is "very little", the intensive option is not merely wasteful — it was never justified on its own terms. This is ordinary requirements thinking (value-orientation, adequacy) applied to the AI infrastructure itself.
Stakeholder communicator and trust builder
This role received significant attention in version 1.0.0, and the syllabus's framing is deliberately demanding.
Building trust means not only sharing AI-supported outputs but actively making transparent what can and cannot be explained, and the reasons behind these limits.
The Requirements Engineer ensures stakeholders are transparently informed about the use of AI, its role in the process, its benefits and its limitations. This includes facilitating learning, negotiation and consensus-building among stakeholders — human-centric activities that are essential to any RE process and that require particular attention when parts of the process are automated or accelerated.
A key aspect is making AI-supported outputs explainable and traceable, and creating space for discussion when ethical concerns or reservations about AI use arise. The syllabus closes with a sentence that is easy to skim and worth taking seriously: building trust means addressing these issues explicitly rather than avoiding them.
Example from the syllabus: in an elicitation workshop, the Requirements Engineer explains which steps are AI-assisted, explains the reasoning behind AI-generated suggestions, notes any limitations in their explainability, and invites stakeholders to raise concerns, question AI-supported results and discuss how sensitive data and AI limitations will be handled on the project.
There is a counter-intuitive claim embedded in this role, and it is worth drawing out because it is the difference between the syllabus's position and ordinary stakeholder management.
The instruction is not "explain the AI's reasoning to stakeholders". It is to make transparent what can and cannot be explained, and why.
Those are different obligations. The first is impossible for genuinely opaque models — you saw in module 4 that a tool may propose a prioritisation it cannot justify. A Requirements Engineer who promises explanations they cannot deliver will eventually be caught inventing one, which destroys trust far more thoroughly than the original opacity would have.
The second obligation is always achievable. "This ranking came from a model that cannot show its reasoning, so I have reviewed the top ten manually against our value criteria and here is what I found" is a statement a Requirements Engineer can make honestly. It names the limit, it says what was done about it, and it gives stakeholders something real to interrogate.
This also explains why the role is grouped with facilitating negotiation and consensus-building. Those activities depend on stakeholders believing what they are told about how conclusions were reached. Overclaiming explainability spends exactly the credibility those activities run on.
According to the syllabus, what does building stakeholder trust in AI-supported RE require?
Risk and compliance manager
Click to flipIdentifying and mitigating legal, ethical and operational risks of AI use — protecting personal data, avoiding bias, meeting regulatory and contractual requirements — including choosing processing options such as local versus cloud, ensuring data minimisation and detecting model drift.
Click to flip backAs risk and compliance manager the Requirements Engineer minimises data, chooses processing locations, and monitors for drift on a schedule. Version 1.0.0 adds environmental stewardship: how AI is used within the process affects energy consumption, and unnecessarily intensive patterns carry environmental, reputational and governance risk. As trust builder, the obligation is not to explain everything but to be transparent about what can and cannot be explained — and to raise ethical concerns explicitly rather than avoid them.