Wings+ March 2026 Edition
AI does not fail in development. It fails in approval. Those who understand where permission sits move earlier.
From the WINGS Editorial Desk
AI is usually described through outputs.
A model that writes.
A system that automates.
A tool that reduces time.
What matters more is what happens before any of that is allowed to exist inside an organisation.
Approvals. Data access. Legal interpretation. Internal risk decisions. The quiet conversations between teams who do not build the system but decide whether it can be used.
That layer is rarely visible.
Most AI projects do not begin in formal programmes. They begin in conversations. Someone notices a broken process. A team builds something small to fix it. It works. Expectations form quickly.
By the time a project reaches formal review, the idea already feels real.
This is where most of them stop.
The organisation was never set up to support them.
For early career professionals, this is the part worth understanding.
The technical layer is visible.
The decision layer is not.
That is where careers accelerate.
Why This Matters Now
AI has moved out of experimentation.
The question is no longer what a model can do. The question is whether it can be used.
Organisations are now dealing with something more demanding than capability.
Data protection rules.
Cross border constraints.
Security requirements.
Internal accountability.
In Europe, the AI Act is beginning to shape how organisations approach risk and oversight. In other regions, regulation is less centralised but no less active.
This shifts the centre of gravity.
AI is no longer just a technology discussion. It is a governance problem.
The pattern is consistent.
Ideas emerge at the edges.
Approval sits at the centre.
Teams build quickly.
Governance arrives later.
If the system around the idea has not been considered early, progress slows the moment it becomes visible.
Most organisations are not struggling to build AI.
They are struggling to approve it.
In many cases, they already know where the risks sit. Addressing them properly would slow everything else down, so they are deferred until they can no longer be ignored.
Case Study: When Governance Arrives Late
In 2023, Italy’s data protection authority temporarily banned ChatGPT.
The system worked.
The issue was how data was handled. Transparency. Legal basis. User rights.
The system paused while governance caught up.
Additional controls were introduced. Disclosures were updated. Processes were adjusted before the service returned.
The pattern is familiar inside organisations.
A system performs well in a controlled environment. Then it meets the real world.
Data behaves differently.
Ownership is unclear.
Compliance questions surface.
At that point, the organisation has two choices. Slow down or stop.
The technology rarely fails first.
The system around it does.
The Hidden Lifecycle of an AI Project
From the outside, the process looks structured.
An idea is proposed.
A prototype is built.
It gets approved.
It goes live.
Inside organisations, it looks different.
A team solves a local problem.
A prototype appears quickly.
It works well enough to generate interest.
Only then do the harder questions arrive.
Where did the data come from?
Who owns it?
What rules apply to it?
Can the system be audited?
If those questions were not part of the design, they become blockers.
Legal teams hesitate.
Security teams escalate.
Procurement slows.
The project does not fail. It loses momentum.
This is where most AI work sits. Between something that works and something that is allowed.
Exclusive Interview
Matt Soltau — VP Global Strategy & Operations, IntelliPaaS
Matt works at the intersection of enterprise technology, governance and regulation, supporting organisations across industry and government in moving AI initiatives from concept to deployment.
Where AI ideas actually begin
WINGS: In theory, large technology initiatives are approved through formal steering committees or governance boards. In practice, many successful projects begin informally within operational teams long before they reach those structures.
From your experience, where do AI initiatives actually begin, and what tends to happen in those early stages that determines whether a project will later survive governance review or stall before reaching production?
Matt Soltau:
In my experience, the most exciting AI initiatives never originated in steering committees. They started on the operational level.
I often see leadership getting trapped in high-level PowerPoint presentations and dashboard reviews while failing to gather raw, unfiltered feedback from the ground. This is where the best ideas come from. An operations team dealing with a specific problem: disconnected manual workflows, data trapped in one system, processes requiring multiple logins, different devices or physical tasks such as printing, scanning and re-digitalising files.
Leadership often gets shielded from these insights. In some cases, processes are so brittle they are almost embarrassing to share at a board meeting. These same processes often present the clearest opportunity for AI.
In one manufacturing organisation we worked with, their new AI programme looked excellent on paper. An architectural review later revealed that well over half of the proposed workflows would have breached PII regulations if deployed as designed.
We solved this by introducing an AI compliance layer that checks for possible breaches, cleans data where needed and routes requests to the most appropriate system.
Proof of concepts are useful for exploring possibilities. The real question is what happens next. Are they designed to move beyond the sandbox environment?
Why AI projects stall inside institutions
WINGS: A common narrative is that innovation fails because organisations are too risk-averse or bureaucratic.
From what you’ve observed, what are the real reasons AI projects fail once governance becomes involved?
Matt Soltau:
Governance does not kill AI projects. It exposes problems that were already there.
In controlled environments, teams build use cases on clean data. Outcomes are well defined, so proofs of concept look strong. Once deployed into real environments, they break.
The reason is simple. Clean data does not reflect reality. Live environments are messy, distributed and cross-jurisdictional.
This does not mean the idea lacks value. It means the surrounding system has not been designed to support it.
Data pipelines need to be reliable. Connectivity across systems needs to be in place. Someone needs to own the space between source systems and AI models.
Legal teams own compliance. But the integration layer often belongs to no one. That gap in ownership prevents projects from scaling, even when the underlying idea is sound.
Governance blind spots
WINGS: You mentioned that a significant portion of proposed AI workflows would have violated data residency rules.
Where do you see the largest governance blind spots emerging today, particularly around data, jurisdiction and regulation?
Matt Soltau:
Organisations can usually tell you which AI model they are using.
Very few can tell you which data sources feed that model, where that data has travelled and how its compliance status has changed over time.
In the manufacturing example, 40% of workflows would have breached national data residency rules. No one identified this until full data flows were mapped.
Another issue is upstream data drift. A supplier changes a schema or a system is upgraded. The data feeding the model changes, but no one flags it. Monitoring typically stops at the model layer, not the integration layer underneath.
The final issue is timing. Regulation is still treated as a future problem. The AI Act and cross-border requirements are approaching, but many organisations are still operating on a “deal with it later” basis.
Those that built governance into their architecture early are in a much stronger position than those trying to retrofit it.
What effective governance looks like
WINGS: Governance is often seen as slowing innovation. Yet organisations that integrate it early tend to move faster over time.
From your perspective, what does effective AI governance actually look like in practice?
Matt Soltau:
Effective governance is not a document. It is infrastructure.
If it is set up properly, compliance happens automatically.
In practice, three things matter.
A maintained register of which data sources feed which AI systems, updated in real time.
Automated alerting when something changes upstream. A new field, a deprecated schema, a provider switch. The alert should happen before it reaches the model.
Clear ownership. One person or team responsible for the integration layer and the relationship between source systems and AI systems.
This often sounds counterintuitive, but organisations that build governance this way move faster.
When regulations change or data shifts, they know exactly what is affected. They respond in days, not months.
Without this, projects pause or get scrapped entirely.
Early career advice
WINGS: Many early-career professionals entering AI focus heavily on technical skills.
From your perspective, what do young professionals often misunderstand about how technology decisions are actually made inside large organisations?
Matt Soltau:
It is easy to focus on the latest technology.
In reality, the best technology does not always win. The technology that fits the regulatory, political and data landscape is the one that gets used.
A strong model without access to compliant data will remain in a controlled environment. It is too risky for production.
Technical skills alone are not enough.
There is increasing demand for people who can translate between legal, technical and operational teams. This requires understanding processes, constraints and priorities across the organisation.
It also requires judgement. The ability to navigate competing interests and sensitivities.
My advice is to understand how data moves through an organisation.
Where it comes from.
Who owns it.
What rules apply to it.
Where it is allowed to go.
If you can map that clearly, you become indispensable to any AI programme.
This is where projects succeed or fail, long before any model is built.
Master that, and you will have a seat at the table.
Career Clarity: Where Hiring Is Actually Moving
Most early career professionals approach AI through tools.
Learning models. Learning frameworks. Learning how to build.
Inside organisations, that is only one part of the picture.
The harder question is whether what has been built can be used.
This is where hiring is shifting.
There is growing demand for people who understand how systems connect.
Where data originates.
How it moves.
What governs it.
Who is responsible for it.
These roles are rarely labelled clearly. They sit between teams.
Legal, engineering and operations do not speak the same language. Someone has to translate.
People who develop this early are pulled into decision-making conversations sooner.
Not because of seniority.
Because they reduce uncertainty.
That is what organisations value most at this stage of AI adoption.
A Note on Bias and Responsibility
Bias in AI is often treated as a technical issue.
In practice, it appears later.
A system is built. It performs well. Then it is tested against real outcomes.
That is when patterns emerge.
Uneven results. Skewed data. Unexpected behaviour.
By that point, the system is already embedded.
Addressing bias becomes a governance exercise.
Reviewing datasets. Adjusting processes. Defining accountability.
This is why bias is not only about models. It is about timing.
When governance enters late, the cost of correction is higher.
Cross Sector Relevance
The same structure appears elsewhere.
In finance, products are shaped by what compliance allows.
In healthcare, data use is defined before systems are built.
In infrastructure, approvals determine what moves forward.
Across sectors:
Permission comes before scale.
Those who understand where permission sits move differently.
They see constraints earlier.
They ask different questions.
They avoid work that cannot progress.
That changes how they are perceived.
Closing
AI is often framed as a shift in capability.
Inside organisations, it is exposing something more familiar.
How decisions are made.
Where responsibility sits.
Who is allowed to move something forward.
The technical layer is visible.
The approval layer is not.
Those who understand both do not just build systems.
They understand which systems will survive.
That is where leverage begins.