AI governance that ships is a set of gates in the pipeline, not a committee at the end

The date on which the European Union's rules for high-risk AI systems would start to bite moved by sixteen months in a single legislative year. When the AI Act (Regulation 2024/1689) entered into force in August 2024, its obligations for stand-alone high-risk systems, the ones used in hiring, credit scoring, education and similar areas listed in Annex III, were due on 2 August 2026. In November 2025 the Commission proposed a "digital omnibus" to defer them. Parliament adopted the text on 16 June 2026, the Council followed on 29 June, and the amending regulation was published in the Official Journal on 24 July 2026. The new dates are 2 December 2027 for Annex III systems and 2 August 2028 for AI embedded in products covered by sectoral safety law, such as machinery and medical devices.

A team that built its compliance program around the August 2026 date has gained sixteen months. A team that built it around a document review before launch has gained a different thing, which is a longer queue. The deadline moved, and the obligations did not go away. Other parts of the Act were never postponed: the bans on certain practices and the AI literacy duty apply since February 2025, the obligations for providers of general-purpose models since August 2025, and the transparency duties of Article 50 apply from 2 August 2026. The omnibus even added a new prohibition, on systems that generate child sexual abuse material and non-consensual intimate imagery, with a transition to December 2026.

Brazil sits in an earlier chapter of the same story. The Senate approved bill PL 2338/2023, a risk-based framework for AI, in December 2024 and sent it to the Chamber of Deputies, where a special committee has handled it. According to the most recent coverage I could verify, from mid-2026, votes had been repeatedly rescheduled, with copyright among the sticking points, and it had not been enacted. Readers should check its current status, and the practical point holds either way. A company operating in Brazil and Europe cannot wait for the legal text to settle before deciding how it governs its systems. The LGPD already applies. Its article 20 gives data subjects the right to request review of decisions taken solely through automated processing that affect their interests, including credit profiles, and to ask for clear information on the criteria used.

My argument is that this uncertainty is a reason to design governance differently. When the legal calendar keeps moving, an organization needs an internal mechanism that can absorb changes in rules without being rebuilt: risk tiers, controls attached to each tier, and evidence collected as engineering work happens. Governance of that kind ships with the product. The alternative, a committee that reviews a slide deck near the end of the project, fails in two ways, since it delays good projects and misses bad ones.

Why the committee at the end fails

A review board that sees a system once, shortly before release, has the weakest possible information and the strongest possible incentive to approve. The project is built, the team has promised a date, and the questions the board can ask are limited to what the presenters choose to show. If the board raises a serious concern, the options are an expensive redesign or an exception, and exceptions accumulate.

Governance of this kind also treats every system the same. The assistant that summarizes internal meeting notes goes through the same process as the model that decides who gets a loan, which makes the process either too heavy for the first or too light for the second. In practice it is too heavy for all of them, and teams learn to avoid it by calling their projects experiments, which is how a system ends up in production without anyone having decided that it should be there.

Start with an inventory and a tier

The foundation is a register of every AI system in use or development: its purpose, owner, model and vendor, the data it touches, who is affected by its outputs, and its current risk tier. Without it, nothing else can be managed, because a company cannot govern what it cannot list. The register should include systems built by third parties and embedded in purchased software, since the company remains accountable for decisions those features make about its customers and employees.

The tier follows from a short list of questions. Does the system make or materially inform decisions about people's access to credit, work, housing or essential services? Does it act on its own, or does a person review each output? Does it process personal or sensitive data? Is it customer-facing? Could an error do harm that is hard to reverse? The EU's categories offer a useful vocabulary even outside Europe: prohibited uses, high-risk uses, uses that carry transparency duties, and the rest. For an internal rubric, three tiers are usually enough.

Controls attached to tiers

Each tier carries a defined set of controls. The set grows with the risk, and the lowest tier is deliberately light so that experiments can move quickly.

Tier	Typical uses	Required before release	Required while running
Low	Drafting help, internal search, summarizing documents for staff	Named owner, entry in the register, data-handling check	Usage logs, a channel for reporting problems
Medium	Customer-facing assistants, routing and prioritization with human review	Evaluation suite with pass criteria, red-team testing, privacy review, human fallback	Monitoring of quality and drift, periodic re-evaluation, incident process
High	Decisions about credit, hiring, claims, eligibility, safety	All of the above, plus documented intended purpose, bias and performance testing by subgroup, data protection impact assessment, human oversight design, legal sign-off	Continuous monitoring, audit trail of decisions, review rights for affected people, scheduled independent review

The names of the controls matter less than the property that each can be checked. A control that says "ensure fairness" cannot be verified. A control that says "report false-negative and false-positive rates for each group that has at least 200 cases in the test set, and have the model owner and the risk lead sign the report" can be checked, and a missing report blocks the release.

Existing frameworks help to fill in the contents. The NIST AI Risk Management Framework, published in January 2023 and extended by a Generative AI Profile in July 2024, organizes the work into four functions: govern, map, measure and manage. ISO/IEC 42001, published in 2023, sets out a certifiable management system for AI, which some customers and regulators accept as evidence of process. Neither tells a company what its thresholds should be, which is a decision for the business, but both supply checklists that save a team from inventing its own.

Put the gates in the pipeline

The step that turns this from a policy into a practice is automation. Each control becomes a check in the delivery pipeline, and the evidence for it is produced by the work itself.

The evaluation suite already exists in a well-run team, so its results are the performance evidence. The suite runs on every change to the prompt, the retrieval index or the model, and a release is blocked if it falls below the threshold set for the tier. The registry of prompt and model versions provides the audit trail of what was deployed when. Data lineage tools show where training and retrieval data came from, which supports the data-protection assessment. Approvals happen in the same tool as the code review, signed by the named roles, so that the record of who accepted which risk sits next to the change it concerns.

A high-risk system then needs no separate compliance project to assemble evidence before an audit. The evidence is a by-product of building it, and an auditor can be shown the pipeline. This is also what makes the program cheap. The marginal cost of governance for a new system in the medium tier is the cost of writing its evaluation cases, which the team should have done anyway.

Consider a claims-triage model that recommends which insurance claims to pay quickly and which to send for investigation. It sits in the high tier, since a wrong recommendation delays or denies payment to a person. The gate asks for an evidence pack that the pipeline mostly assembles. It contains the intended purpose in two sentences, the evaluation results with intervals, false-negative and false-positive rates by region and by customer segment, the data sources and the legal basis for using them, the human-oversight design, and the monitoring plan. The release authority reads the pack, asks questions and signs or refuses.

The oversight design deserves scrutiny, because oversight can be nominal. A reviewer who sees a recommendation with no reasons, under a quota of two hundred claims a day, will agree with the model nearly every time. The EU Act asks for oversight that is effective in practice. A measurable test is the override rate. If reviewers overrule the model in 0% of cases, either the model is perfect or the review is a rubber stamp, and the second explanation is more likely. Track overrides, sample them monthly, and look at whether the reviewers' corrections are right.

Vendors and the shared load

Much of a company's AI exposure arrives inside purchased software. The Act distinguishes providers, who build or place systems on the market, from deployers, who use them under their own authority, and it gives deployers duties of their own for high-risk systems: using the system according to its instructions, assigning competent human oversight, monitoring operation, and keeping the logs the system generates for an appropriate period, which the Act sets at no less than six months. Contracts should therefore ask vendors for what the company needs in order to meet those duties: documentation of intended use and limitations, access to logs, notice of incidents and material model changes, and a statement of how customer data is used. A vendor that cannot provide them is a risk to put on the register.

Decision rights, and who can say no

Gates need people with the authority to hold them. For the high tier, name a release authority, usually a risk lead who is independent of the delivery team, and write down that the authority can stop a launch. State who can grant an exception, for how long, and how it is recorded. Without such an owner, a gate is a suggestion, and the pressure to ship will treat it as one.

Keep the fast lane honest too. If a low-tier project takes six weeks to clear, teams will disguise their projects as something else. Set targets for each tier, for example a day for low, a week or two for medium and a month for high, and track them. A governance team that measures its own lead time is far more likely to be trusted.

Treat rules as moving constraints

The omnibus shows that the date of an obligation is the least reliable part of a regulation. The structure is more stable: the risk-based classification, the emphasis on documentation, human oversight, data quality, transparency and post-market monitoring. A design that satisfies the structure for each tier holds up when deadlines change. The sensible practice is to build to the strictest likely requirement for the tier and to treat the legal calendar as the time available, not the design target.

The cost of failure is also large enough to justify the effort. The AI Act's penalties for prohibited practices run to the higher of 35 million euros or 7% of worldwide annual turnover, and those for most other violations to 15 million euros or 3%. For a company that sells into Europe from elsewhere, these provisions can apply, since the Act reaches providers and deployers whose systems' outputs are used in the Union.

A governance program should be judged by outcomes it can measure. Track the share of systems in the register with a current review, the median time to clear each tier, the number of incidents and how quickly they were detected and closed, and the number of exceptions granted and still open. Rising approval times in the low tier are a warning that the process is drifting toward the committee it replaced. A falling share of systems with current reviews means the register has become decorative.

A first quarter

A reasonable first quarter for a company without a program looks like this. In the first month, build the register by asking each business unit to list what it uses, including purchased tools, and assign provisional tiers. In the second, define the three tiers and their controls on one page, and connect the evaluation suites of the two or three most important systems to a release check. In the third, name the release authority for the high tier, run one system through the full path as a rehearsal, and measure how long it took. The rehearsal will reveal which controls are unclear or impractical, and those are better discovered on a practice run than during an audit.

Sources

1. Regulation (EU) 2024/1689 (Artificial Intelligence Act), Official Journal of the European Union, 12 July 2024.
2. Regulation (EU) 2026/1744 amending the AI Act ("AI Omnibus"), published in the Official Journal on 24 July 2026; Future of Privacy Forum, The AI Act implementation timeline: what changes under the AI Omnibus; Gibson Dunn, EU AI Act Omnibus Agreement: Postponed High-Risk Deadlines and Other Key Changes.
3. Brasil. Projeto de Lei nº 2.338/2023 (marco legal da inteligência artificial), aprovado pelo Senado em 10 de dezembro de 2024; tramitação na Câmara dos Deputados, acompanhamento da imprensa especializada até meados de 2026.
4. Brasil. Lei nº 13.709/2018 (LGPD), arts. 6 and 20.
5. National Institute of Standards and Technology (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0); and NIST AI 600-1, Generative Artificial Intelligence Profile (2024).
6. ISO/IEC 42001:2023. Information technology, Artificial intelligence, Management system.