Sombra's 2026 AI governance guide asks enterprises to document how each safeguard is enforced at runtime. For an AI workflow in a regulated company, that means stating where each control lives and what evidence it produces.
Sombra, an engineering and AI consulting firm, published a guide to AI regulations and governance in 2026 that names the documents it expects enterprises to maintain. Two of them do most of the work. The compliance matrix maps each control to clauses in the EU AI Act, the NIST AI Risk Management Framework and ISO/IEC 42001. The control catalog lists each safeguard and how it is enforced at runtime. The guide's warning is direct: proofs of concept lacking this evidence won't scale to production in regulated markets or in industries such as finance and healthcare.
The matrix tends to get attention first because it looks like regulatory work, and quality and compliance teams already know how to build traceability tables. I think the catalog deserves the earlier start, because the phrase "enforced at runtime" asks a question many pilots never answer. It asks what the system actually does, at the moment of use, to make a safeguard hold. For a mid-market company putting an AI agent into a complaint intake process or an invoice exception queue, that answer determines whether the pilot can move forward.
Take a common safeguard: a qualified person reviews and approves an AI-generated draft before it becomes a record. That sentence can be enforced in very different ways. It can live in an SOP that staff are trained on, which means the control depends on people remembering it. It can be checked after the fact, with a weekly report that flags drafts filed without a recorded approval. Or the workflow can refuse to file the draft until someone with the right role approves it, and store who approved, when, and which version of the output they saw.
Each of these may be defensible depending on the risk, and the catalog should say plainly which one you have. A control that exists only in a procedure document is still a control, but an auditor will ask how you know it was followed, and the answer is often a sample of records. A control the system enforces produces its own evidence every time it runs. That difference is what Sombra's guide is pointing at when it ties production readiness to evidence.
Each entry should name the risk the control addresses and describe the control in one or two sentences. It should state where the control is enforced, meaning the system and workflow step where it sits and the configuration or code that holds it in place. It should name the evidence the control produces and where that evidence is stored. It should also name an owner and describe how the control is tested, including what happens when it fails, such as whether the workflow stops, routes the item to a person, or logs the failure and continues.
The operating model matters here. Sombra's guide describes three models, Buy, Hybrid and Build, each with its own compliance strategy. If you buy an AI capability inside a vendor product, some safeguards are enforced by the vendor's software and you can only configure what the vendor exposes. Your catalog entry for those controls has to say so, and the evidence may come from vendor logs you need contractual access to. With a hybrid or built system you control more of the enforcement point, which also means more of it is yours to test and maintain.
The hardest entries to write are for approvals that happen outside any system. Before Laminar built LeaseIQ for Healthpeak Properties, its lease approval, legal document review and tenant improvement workflows had run on email, spreadsheets and phone calls. An approval given over the phone cannot be enforced or evidenced at runtime. If the step an AI agent feeds into still runs on email, the catalog will expose it, and the fix is workflow work that has to happen before or alongside the AI work.
Change control is the second source of friction. A runtime control is tied to a specific configuration, and AI components change as models get updated and prompts get edited. Each change can move or weaken an enforcement point, so the catalog should be a controlled document that your change process updates, with a check that each affected control still produces its evidence after the change.
Staff reaction is the third. Hard stops slow people down, and users who moved faster during the pilot may push back when the production version refuses to file without an approval. The catalog gives you a place to record where you chose detection over prevention and why, which is a better answer to that pushback than an unexplained rule.
Dealing with a similar challenge?
We work with mid-market companies in regulated industries to build AI workflows that actually hold up.
Let's TalkSean Cummings
Founder of Laminar Consulting Services. Specializes in AI workflow automation for regulated industries — medical device, financial services, and complex logistics operations.