Building a high-risk AI system no longer starts with business requirements alone. Regulation becomes part of the requirements engineering process from the very beginning.
by Ivan Pletin, Senior Business Analyst at Sigma Software
As AI moves into regulated and high-risk domains, regulation itself becomes a source of product requirements. For high-risk AI systems, requirements engineering becomes the foundation of compliance, determining whether regulatory obligations are captured or missed before implementation begins.
The newest source of requirements
The current case in point is the European Union’s AI Act. Transparency obligations apply from 2 August 2026. The high-risk regime — covering biometrics, critical infrastructure, education, employment, and other sensitive domains — applies from 2 December 2027, with fines reaching €35 million or 7% of global turnover at the Act’s top tier. Timing cuts both ways: systems already on the market before the deadline benefit from transitional provisions, while anything launched after faces full obligations from day one. A product entering development today will be delivered straight into the enforcement window.
Structurally, the Act does what GDPR did for data protection: regulatory articles become a first-class source of requirements, alongside business stakeholders. The engineering discipline that connects the two is requirements traceability.
How traceability works
The instrument is deliberately simple: a traceability matrix mapping each article to the constraints it imposes on this specific product, and each constraint to the user stories that implement it. Forward, it proves nothing was missed. Backward, it answers “why are we building this?” in one lookup.
The analytical work sits in translation, because the Act is not written as a specification. Article 12 requires that a system technically enable automatic recording of events — without defining “events.”
Consider an educational platform built for a public-sector client, a domain the Act explicitly classifies as high-risk. Knowing the system stores students’ personal data and academic records, a business analyst converts the abstraction into testable requirements: log who changed which data, and when. Add an AI agent that grades student assessments, and the requirement deepens — the system must capture not just the grade but the reasoning behind it: why this decision, on what basis, at what time.
The audit trail is designed here, in the spec, before any logging infrastructure exists.
How compliance is engineered at Sigma Software
This is how requirements engineering works at Sigma Software: we track evolving AI regulations as they take shape and translate their implications into practical product requirements for our clients’ systems — so that by the time enforcement arrives, compliance is already in the specification, not on a to‑do list.
This requirements discipline is embedded directly into our AI‑native SDLC and agentic orchestration workflows. In projects where AI agents already operate in regulated environments — from public‑sector education platforms to financial data processing systems — traceability and compliance constraints are engineered upfront, not retrofitted.
Compliance for high-risk AI systems is decided at specification time. That is where regulatory obligations become engineering constraints, and where the audit trail begins — long before any infrastructure is built.
Learn more about how Sigma Software approaches AI compliance: https://sigmasoftware.ai/
