Data, Legal and Compliance Risks

The second group of risks comes not from what the model is, but from what happens when your project's data meets someone else's infrastructure and someone else's law.

A note the syllabus itself attaches, and which this course repeats: the regulatory examples here reference EU rules as illustrations. They should be adapted to the legal framework and cultural context of each project. Nothing in this lesson is legal advice.

Data leakage

Sensitive or confidential information can be unintentionally exposed when used with external AI services. The syllabus adds the sting in the tail: even anonymised data may be identifiable if combined with other sources.

Example: in a healthcare project, anonymised transcripts of patient interviews are sent to a cloud-based summarisation service outside the European Union. A data protection authority later determines that unique combinations of symptoms and treatment dates in those transcripts are sufficient to identify individual patients. That constitutes a GDPR violation, and the resulting fine is very high.

The lesson inside the example is the part worth carrying: anonymisation is not a binary property of a document. It is a property of a document in combination with everything else available. A transcript with names removed can still be re-identifying if the clinical details are rare enough. A Requirements Engineer who strips names and considers the job done has misunderstood the risk.

Intellectual property violations

AI outputs may reproduce protected or confidential material from training data or from earlier prompts, raising legal and contractual risks.

Example: the AI produces a requirements specification containing verbatim text from a competitor's product manual.

The "or earlier prompts" clause deserves attention. In a shared or team context, material one person pasted in can surface in another person's output. Whether a given service does this depends on the service, and it is a question worth answering before the tool is adopted rather than after.

Transparency obligations

Regulations such as the EU AI Act introduce a legal requirement to disclose when content is generated by AI. The syllabus is unusually careful here, and the care is the examinable part: these rules are quite specific and do not apply to all outputs.

For text output — which is most of what RE produces — the obligation to label content as AI-generated applies specifically when the text is intended to inform the public on matters of public interest.

Most typical RE artefacts do not fall into that category. Internal specifications, user stories and backlog items are not published to inform the public on a matter of public interest.

There is a second, equally important carve-out. Disclosure is not required if the AI-generated output has been subject to a process of human review and a person or organisation takes editorial responsibility for its publication.

That exemption maps onto RE practice almost exactly. It aligns with the principle that a Requirements Engineer, Product Owner or another stakeholder must always validate and take ownership of requirements before they are accepted. In other words: if you are doing the human curation the rest of this syllabus demands, you are already doing the thing that satisfies the exemption.

Example: a team uses AI to generate a published report, drawn from approved requirements, describing how new financial software complies with government transparency regulations. That report is a matter of public interest. If it were published automatically, with no compliance officer or project lead reviewing it and taking responsibility for its content, it would likely breach AI transparency law — and the organisation could face penalties for presenting AI-generated analysis on a public matter without the required disclosure or human oversight.