Ask a team building an AI feature for a hospital what compliance costs them. They'll point to the audit that showed up after the interface was already locked. That timing tells you something. Compliance entered the process as a checkpoint, not a constraint.
This is constraint inversion. When a project stalls, look for the restriction that narrows the problem instead of opening it up. Regulated industries hand you three restrictions for free. Most teams read them as tax. They're the design brief.
Audit trails are interface decisions
Velt.dev puts it specifically: "the decision chain: what data the model used, which version ran, how confident it was." That's an interface problem. Somewhere in the product, a person has to see that chain at the moment the decision matters.
The EU AI Act's Article 14 calls for "meaningful" human oversight. SEC Rule 17a-4 requires six years of immutable, auditable records. Both rules describe a screen before they describe a database. Fuselab's guide makes the same point from the design side: what matters to a regulator is the specific screen a user was viewing when they took action. If your AI feature can't surface that at the moment of approval, you built a product that was never designed for its user.
Explainability kills the vague AI feature before it ships
The arxiv paper on explainability in regulated engineering found that 9 of 10 participants rejected AI outputs they couldn't explain. A medical device engineer put it plainly: "If an AI tool suggests a modification but doesn't explain why, we can't just accept that blindly."
An automotive participant said every design decision has to meet strict safety standards, so they manually check each diagram. Outside regulated industries, that instinct barely exists. A generated summary, a chatbot reply: nobody asks why.
That missing "why" requirement is what produces the vague AI feature everyone complains about. Explainability forces the team to decide, before the first meeting ends, what the model is allowed to claim.
Accountability makes the override path the actual feature
Fuselab identifies the override path as the credibility mechanism for the entire product. A healthcare professional needs confidence mapped to clinical documentation formats. A chatbot doesn't deliver that.
That scoping decision is one an unconstrained team would spend weeks debating in the abstract. A regulator makes it concrete: someone, by name, has to own the override.
Velt.dev points to the most common compliance gap in enterprise AI: the system touches regulated data through a service account, with no record of which person started the request. Build the named override first. The audit log and the interface follow from that single decision.
The cost is in the sequencing
Mastercard's analysis lands in the same place: when compliance arrives after key decisions are already made, it creates friction. That friction is a sequencing problem.
David Natroshvili wrote in Forbes: "Companies struggling most with compliance aren't being held back by regulations, but by how they think about them." Regulated builds do take longer. Fuselab puts the timeline at 5 to 9 months, about 50% more than a general AI project. That extra time buys a spec that exists before implementation starts.
The FDA cleared 6 AI-enabled device functions in 2015. By 2023, that number was 223. Meanwhile, 59 new federal AI regulations shipped in 2024, double the prior year. Regulation is speeding up. If your product roadmap still treats compliance as friction to negotiate away, what happens when the rules double again and you still have no spec?
.webp)
.webp)
.webp)
