Privacy, security, fairness, and model-risk review cost less at the framing gate than at the door to production. What each gate should check, what to build controls against while the rules keep moving, and who owns the function.
Most programs schedule legal, privacy, and risk review for the weeks before launch. By then the decisions that created the exposure are already built: which data the system uses, what it decides without a person involved, what someone sees before it acts. A review at that point either forces rework or gets waived under delivery pressure, and a team that has been through it once learns to keep the next use case away from the reviewers for as long as it can.
The same reviews are cheaper at the front, where the answer changes the design instead of the schedule. They also attach to decisions the program is already making, so they do not need a process of their own.
A use case that cannot clear privacy, security, fairness, and, where it applies, model-risk review does not advance, whatever the value case says.
At Frame, while you are still deciding whether the use case is worth funding, confirm the data can be used for this purpose under the terms it was collected under, and classify the use case for exposure: who it affects, what decision it influences, and whether that decision is consequential for a person. At Prove, confirm the approach can meet the bar that classification sets, including the evidence you will need to demonstrate it. At Deliver, confirm the notices, the human oversight step, the logging, and the documentation are live before anyone outside the team is using the system.
Some use cases come out of this narrower than they went in. The result may be an approval step in the middle of the workflow, a confidence threshold below which the case routes to a person, or a decision that stays with a person entirely and the system only prepares. Those are legitimate outcomes, and each one costs far less to reach at Frame than after the build.
A control the delivery team has learned to route around stops providing assurance to anyone, including the people who signed off on it.
The rules move faster than any program roadmap. Deadlines slip, state laws are replaced within a year, and cross-border rules can apply whether or not you have a presence in the jurisdiction. Controls written against a particular statute get rewritten when it changes.
Most regimes share a durable core: clear notice when an automated system makes a consequential decision, a route to human review, an opt-out where one is owed, and documentation that holds up in an audit. Controls built to that core survive while the specifics churn.
The slow part is the inventory. Listing every AI system in the company, including the ones that arrived inside a vendor product and the ones a team built on its own, and classifying each for exposure, takes longer than teams expect and does not get shorter by waiting for a deadline to be confirmed.
Build roles are easier to fund than governance roles, so they get filled first. The gap shows up later as missing impact assessments, an incomplete system inventory, and audit trails nobody wrote at the time, all of which then have to be reconstructed against someone else's deadline.
The function needs an owner. In larger companies that is usually a named executive with a direct line to the CEO and the standing to stop an initiative that is technically strong, commercially attractive, and carrying risk the company will not accept. Smaller companies give the same responsibilities to a cross-functional group that sits in every gate review. Either arrangement works if the role can stop a use case and is in the room from Frame onward.
Tell us the process or system you are trying to improve, and we will tell you what it would take to change it.