TwinLadder Weekly
Issue #31 | March 2026
Header Image: /images/newsletter-31-governance-delegation.jpg
Credit: Photo by RPA studio on Pexels (free license, no attribution required)
The Governance You Didn't Delegate
Editor's Note
I spent last week reading two parallel LinkedIn threads that, between them, had over 200 comments from AI governance practitioners. Not marketers. Not prompt engineers. Senior people — board advisors, compliance leaders, system architects, a public prosecutor — arguing about where AI governance actually lives.
The striking thing was not that they disagreed. It was that they were having two different conversations about the same problem.
One thread was about authority — who owns the decision, who answers for the outcome, and what happens when nobody can say. The other was about architecture — whether the system can actually be stopped, and what happens when the safeguard is a policy document rather than an engineering constraint.
Both threads converged on the same uncomfortable conclusion: most organisations believe they have AI governance. They have policies, training, monitoring dashboards, and compliance committees. But none of those things can answer the question that actually matters in enforcement:
When your AI system executed that action — was it allowed to?
And if the answer depends on whether a person remembered to check — you do not have governance. You have hope with documentation.
This newsletter is about what I found when I started mapping that gap against Article 4. [cite:eu-ai-act-article4]
— Alex
The Three Governance Models You Already Have (And Which One Actually Works)
By Alex Blumentals, with Liga Paulina and Edgars Rozentals
I showed Edgars a simple test last Tuesday. I asked him to classify the safeguards in a contract review workflow — the kind a mid-sized law firm runs every day.
A lawyer uses an AI tool to review a vendor agreement. The tool flags potential issues. The lawyer reviews the flags and sends the contract to the client.
"Three governance models exist for this workflow," I said. "Tell me which one your old firm used."
Edgars did not hesitate. "The second one. Obviously."
Here are all three.
Model 1: Instrumentation
The AI flags 15 clauses as potential issues. The lawyer sees the flags. Nothing prevents the lawyer from ignoring every flag and sending the contract unchanged. The system logged the risk. The risk travelled alongside the action. But the action was never bound by it.
If clause 7 was a liability cap that should never have been accepted — the flag existed. The system "knew." The contract went out anyway.
This is monitoring. It is not governance.
Model 2: Behavioural Safeguard
Same flags. But firm policy says: "All AI-flagged high-risk clauses must be reviewed and signed off before sending." The lawyer is trained on this. There is a checklist.
Friday afternoon. Deadline pressure. The lawyer reviews 12 of 15, skips the remaining 3, ticks the checklist, sends the contract. The policy existed. The training existed. The behavioural safeguard failed because it depended on a human being consistent under pressure.
I showed this to Liga. She pulled up Article 4. [cite:eu-ai-act-article4]
"The regulation says organisations must ensure sufficient AI literacy," she said. "But what does literacy defend against in Model 2? The lawyer was literate. They understood the risk. They knew the policy. They skipped it because they were human, under pressure, on a Friday afternoon."
"So what is the compliance defence?" I asked.
"There are only two options," Liga said. "Either the lawyer was not competent — which contradicts the training records. Or the lawyer made a judgment error despite competence — which proves that training alone does not prevent harm."
"Either way, you lose."
That is Model 2. Most organisations live here. They believe they have governance because they have policies and training. They have a behavioural safeguard that depends on every person, every time, under every condition, doing the right thing.
Model 3: Structural Constraint
The AI flags 15 clauses. The system will not generate the final document until every flagged clause has been marked as "accepted," "modified," or "escalated" — with the lawyer's name and timestamp on each one. If three flags remain unresolved, the system refuses to produce the output.
The lawyer cannot skip clause 7. Not because they were trained not to. Because the system will not let the contract exist in sendable form until it is resolved.
I asked Edgars how many enterprise AI deployments he has seen that operate in Model 3.
"In production? Where the system actually refuses? Maybe one in ten. And that one is usually in financial services, where the regulator has already asked."
The Vendor Problem Nobody Is Talking About
Here is where this gets uncomfortable for mid-sized European companies.
Most organisations do not build their AI systems. They buy them. Workday for HR. Salesforce for sales. SAP for operations. Microsoft 365 for everything else.
These vendors embed AI features that activate by default or through a simple settings toggle. [cite:workday-ai-features] [cite:salesforce-einstein] [cite:sap-business-ai]
The AI in these systems makes decisions before your people see anything.
| System | What the AI Decides Before Humans See It | What the Human Sees |
|---|---|---|
| Workday Recruiting | Filters 500 applicants → surfaces 50 "recommended" | The 50. Not the 450 that were eliminated. |
| Salesforce Einstein | Scores and ranks leads by "likelihood to convert" | Leads in ranked order. Not the scoring model. |
| SAP Procurement | Recommends suppliers based on risk/cost/performance weighting | The recommendation. Not the eliminated vendors. |
| Microsoft Copilot | Summarises meeting notes, prioritising "key decisions" | The summary. Not what was left out. |
Your people are trained. They understand AI risk. They follow policy. They review what they are shown.
But they were never shown the full picture. The system made the consequential filtering decision upstream. The human's "review" is downstream of a decision they did not authorise, cannot see, and were never asked to evaluate.
Under Article 4, the deployer — your organisation — is responsible for ensuring sufficient competence. [cite:eu-ai-act-article4-context] But your vendor designed the system so that competence cannot be exercised at the point where it matters. There is no moment in the workflow where a competent person can evaluate the filtering decision, because the filtering happened before they entered the picture.
That is not a training gap. That is an architecture gap. And the liability sits with you, not with the vendor.
When Filtering Is Already Execution
I put this to Kamilla Harcej, who has been developing what she calls the "execution boundary" framework — the architectural point where a proposed AI action must be authorised or refused before it becomes real.
Her response shifted how I think about this entirely.
"Filtering 500 candidates to 50 isn't just pre-processing," she said. "It's already execution. The system has changed what is possible next."
That reframing matters. We tend to think of execution as the final action — the email sent, the contract signed, the candidate hired. But the moment the system narrows options, ranks outcomes, or removes alternatives, it has already acted. It has changed the available reality. Everything downstream operates on a version of reality the system shaped.
Which raises a question I think the industry needs to confront honestly:
If the system has already changed what is possible before a human sees anything — and the human cannot see, interrogate, or adjust the algorithm that made that decision — is the deployer compliant with Article 4?
Because Article 4 requires competence "in the context the AI systems are to be used in." [cite:eu-ai-act-article4-context] If the context includes an invisible filtering decision that your staff cannot evaluate, then competence cannot be exercised in that context. The regulation requires something the architecture makes impossible.
I asked Liga whether this means every SaaS system with opaque AI filtering is structurally non-compliant for European deployers.
She paused longer than I expected.
"Not automatically," she said. "But it means the deployer has to demonstrate what compensating measures they took. And 'we trained people to review the output' is not a compensating measure for a decision they never saw. The compensating measure would have to be: we audited the filtering logic, we tested for bias, we obtained transparency from the vendor, or we chose a vendor that provides visibility."
"And if the vendor does not provide visibility?"
"Then the deployer has chosen a system where Article 4 competence cannot be exercised at the filtering stage. That is a risk the deployer must document, mitigate, and defend. And most have not."
Edgars was blunter. "If you are using a system where you cannot see what it filtered, and you cannot explain why a decision was made, and you cannot override the filtering — you are not deploying AI. You are being deployed by it."
The Competence Question
Your HR team uses an AI recruitment tool. The system screens 500 applications for a senior compliance role. It surfaces 50 candidates as "recommended."
Your HR manager — trained, experienced, Article 4 compliant — reviews the 50. She selects 8 for interviews. She hires one.
Six months later, a rejected candidate files a discrimination complaint. Their application was among the 450 the system filtered before your HR manager saw anything. The candidate has a strong CV. They meet every qualification listed in the job posting.
The regulator asks your HR manager: "Why was this candidate excluded?"
She says: "I never saw their application."
The regulator asks: "Who decided to exclude them?"
She says: "The system."
The regulator asks: "Who authorised the system to make that decision?"
Silence.
Your organisation has training records, AI literacy assessments, a governance committee, and a policy that says "human review of all recruitment decisions."
But the human reviewed 50 out of 500.
The system reviewed 500 out of 500.
Who governed whom?
What This Means for Article 4 Compliance
Liga mapped the three governance models against the regulation. The result is not comfortable.
| Governance Model | What It Proves to a Regulator | Article 4 Defence Strength |
|---|---|---|
| Model 1: Instrumentation | "We logged the risk" | None. Logging is not governance. |
| Model 2: Behavioural | "We trained our people and they were supposed to check" | Weak. Requires proving that training prevents harm — which it demonstrably does not under pressure. |
| Model 3: Structural | "The system cannot execute the action without human authorisation at this specific checkpoint" | Strong. You have defined the boundary, built the constraint, and can evidence that it works. |
"Article 4 does not specify which model to use," Liga said. "But the enforcement test is practical: did your measures actually prevent the harm? If the answer is 'we trained people but the system executed anyway,' you are in Model 2 territory. And Model 2 does not survive enforcement."
The regulation carries fines up to EUR 15 million or 3% of global turnover. [cite:eu-ai-act-penalties]
What To Do
-
Classify your safeguards. Take your top 5 AI-integrated workflows. For each safeguard (review step, approval gate, compliance check), ask: is this instrumentation (logged), behavioural (someone is supposed to check), or structural (the system enforces it)? If more than 80% are behavioural, your governance depends on human consistency. That is not a defensible compliance position.
-
Map pre-visibility filtering. For each AI vendor system you use, ask: what does the AI decide before our people see the output? Write it down. If you cannot answer — and most organisations cannot — you have delegated authority you did not know you delegated.
-
Ask your vendors the hard question. "Can our staff see what your AI system filtered, ranked, or excluded before presenting results? If not — why not, and what are you building to change that?" Put it in writing. Make it a contract negotiation point at renewal.
-
Test your governance under pressure. Run the Friday afternoon test. Take your most critical AI-assisted workflow and ask: if our most junior employee used this system on their worst day — what prevents a bad outcome? If the answer is "they are supposed to review it" — that is behavioural. It will fail.
-
Start measuring authority delegation. For each AI system, ask: who authorised this system's decision scope? Not "who approved the procurement" — who defined what the system is allowed to decide? If nobody did, the system defined its own scope. And you are liable for the consequences.
-
Build the evidence trail now. When the regulator asks "what did you do to ensure sufficient AI literacy?", your answer needs to be more than training records. It needs to show that you identified where behavioural safeguards were insufficient, where structural controls were needed, and what you did about the gap. That is a governance posture, not a training programme.
Learn to Map This in Your Organisation
Our Leadership and Mastery courses now include a Delegation Discovery Workshop — a structured exercise where you map your AI workflows, classify every safeguard as instrumentation, behavioural, or structural, and stress-test your governance under pressure.
Participants leave with a Workflow Authority Map and a Governance Model Classification Matrix — tangible deliverables that show exactly where your organisation relies on human consistency instead of system enforcement.
If this newsletter made you uncomfortable about your compliance posture, this module will show you precisely where the gaps are — and what to do about them.
Explore our courses | Take the free Quick Scan assessment
Quick Reads
- EU AI Act Article 4 full text — The one sentence that created a EUR 15 million obligation. Read it, then read it again.
- Kamilla Harcej on the Execution Boundary — "If a system cannot refuse, it cannot govern. It can only act." The sharpest articulation of Model 3 I have found. Follow her newsletter "The Execution Boundary" on LinkedIn.
- Catherine Gunnell: AI Governance Starts with Mandate, Not Monitoring — "AI authority rarely moves through formal approvals. It migrates quietly through defaults, thresholds, routing logic." Essential reading for anyone who thinks governance is about policies.
- Catherine Gunnell: AI Governance Becomes Real in the Inner Rings — Where accountability diffusion, classification theater, and visibility gaps break enterprise governance in practice.
- Catherine Gunnell: Why Most Enterprise AI Programs Stall After the Pilot — "The model works. The workflow doesn't." Why pilot success creates a false sense of progress.
- OWASP AI Security Verification Standard — If you are evaluating AI vendor claims, this is the emerging benchmark for what "secure" should mean.
- Twin Ladder Standard v1.0 — Our open-source competence assessment framework. Six pillars. Four maturity levels. Free methodology, paid implementation.
- Article 4: What Legal Teams Must Know Now — Our deep-dive on what the regulation actually demands — word by word, phrase by phrase.
One Question
For your most critical AI system — the one that touches customers, employees, or regulated decisions — answer honestly:
If that system executed an action that caused harm tomorrow, and the regulator asked "was the system allowed to do that?" — would your answer be "yes, we defined and enforced the boundary" or "we trained people to check"?
If it is the second answer, you do not have a training problem.
You have an architecture problem dressed up as a compliance programme.
TwinLadder Weekly | Issue #31 | March 2026
Helping European professionals build AI competence through honest education.