A working knowledge of AI is not optional for those who carry it. Roughly one in five executives is considered genuinely AI savvy. A large majority privately admit they overstate how much they understand. Nobody says it out loud, because a knowledge gap at the top reads like an admission of weakness. That silence is the real finding. Not that the workforce knows too little. That leadership was left alone with the harder half.

The comforting reflex

There is a reflex that sounds right and points the wrong way. It says: leaders must model AI, so they should use the tools themselves. Half true. Personal tool use is pleasant, but it is not the competence that matters.

An executive does not need to train a model. An executive needs to judge whether a project is sound. That is a different class of knowledge. Operating a chat assistant fluently tells you nothing about whether a high-risk system is even permissible under the law, what it costs to run over five years, or how you would recognize that the rollout succeeded. The operation is visible. The judgment is what counts.

Why does standard training miss the top? Because it is built for the broad base. Paths to senior leadership never required data or AI knowledge. People who rose needed budgets, law, people, negotiation. AI was not a prerequisite. So today the employee curriculum gets passed upward, the same basics, the same click-throughs. It misses leadership because leadership decides elsewhere. The workforce applies AI. Leadership answers for what happens with it at scale. Those are not the same learning objective.

There is also a quiet incentive to leave the gap open. Training for the base produces attendance rates, and rates can be reported. An honest format for leaders produces something else first: the realization of how much the room does not yet know. Nobody enjoys reporting that upward. So the comfortable version wins, and the uncomfortable, more important one waits for later. Later rarely comes.

The harder half

What should leadership be able to do instead? The judgment splits across four domains, and none of them can be delegated to IT.

1. Protect. Governance, law, ethics. Which regulatory frameworks apply, what triggers a high-risk classification, where the line runs between permitted and forbidden. In a regulated or public context this is not a bonus. Human final say is non-negotiable, and anyone who cannot judge that signs blind.

2. Prioritize. Value, economics, vendor choice. How do you measure whether an AI rollout succeeded? Not in minutes saved, but in an outcome you can tie to the goals of the organization. And what does the whole thing cost over time, not in the pilot year? Miss the full cost structure and you mistake a cheap entry for a cheap solution.

3. Prepare. Workforce, roles, human-AI collaboration. Which role changes, which stays, who carries which context knowledge from here on. The most thankless task, because it is never finished.

4. Position. Strategy, differentiation, business model. Where AI shifts the rules, and what that means for you.

Serve only one domain and you make half decisions. The dangerous part: half decisions feel like whole ones, until someone demands the missing half.

A concrete case

A large organization in a heavily regulated environment took AI training seriously. It rolled out e-learning: foundational AI knowledge for everyone, plus specific courses on using individual tools. Done well. Well received. The participation figures were presentable.

And still the decisive part was missing. For the leadership level there were no targeted measures on the topics only leaders can own. AI governance. The requirements of European AI law for high-risk systems. Criteria for when an AI rollout counts as successful. The long-term cost trajectory and the question of where, given good domain context, costs can actually be reduced. And policy as code, the practice of turning rules into something a machine enforces, rather than a PDF nobody reads.

The pattern is uncomfortably symmetric. The workforce was enabled to use AI. Leadership was left alone with the question of whether and how to be accountable for it. The easy half was trained. The hard half was skipped. Not out of neglect, but because the hard half is not a finished module you can buy and deploy.

Sequence beats speed

There is a second mistake, and it tempts more than the first. It is called skipping ahead. An organization declares itself AI-first, and leadership wants to start with the big themes right away. Agentic systems, business-model reinvention, the frontier. Ambitious. Usually premature. Because a stated ambition is not the actual maturity of your leadership. One describes where you want to be. The other, where you stand.

A sensible order has three stages, and it does not shortcut. First the non-negotiable minimum: recognize risk, use the tools as a spark for curiosity, nothing more. Then the balancing act between control and value: from risk-only oversight to structured experiments that weigh effort against benefit. Only then the frontier, with advanced concepts and decisions under real uncertainty. Jump to stage three without an honest starting point, and you overwhelm leadership and call it incompetence, when only the sequence was wrong.

So the opening question is not how far do we want to go. It is: where do we actually stand? And the answer comes not from the mission statement but from a sober look at your own room. Is AI discussed precisely, or as a catch-all? Are risks named or smiled away? Can anyone connect a use case to a business outcome?

You can train the workforce as thoroughly as you like. It does not replace the judgment at the top. The easy half can be bought. The hard half you have to learn yourself.

Read the article in german language: https://www.lezgus.de/ki-kompetenz-der-fuhrung-warum-die-belegschaft-geschult-wird-und-der-vorstand-nicht/

Die Zweite Meinung (german blog)

It is not the model. It never was.

The bottleneck is the unglamorous work of taking what your organization knows and writing it down in a form a machine can read. Most of that knowledge has never been written down at all. That is the whole problem, and almost nobody has budgeted for it.

The flight to the wrong Portland

Picture the canonical demo. You tell the agent: “Book my flight to Portland for the client meeting tomorrow.” A chatbot would ask you a question. An autonomous agent acts.

So it books Portland, Maine. Your client sits in Portland, Oregon. The agent did not fail because the model was weak. It failed because it never knew the client is in Oregon, which travel vendors are approved, or where you are flying from. None of that lives in the model. It lives in your organization.

With a chatbot, a human catches the mistake before it costs anything. With an autonomous agent, the mistake is executed, paid for, and waiting at the wrong gate. The model was confident. It was confidently wrong.

A language model is stateless by design. It knows language. It does not know your workflows, your approval chains, or your operational reality. That gap is not a model problem you can buy your way out of. It is a context problem you have to build your way out of.

This is the part the market gets backwards. The industry sells autonomy as a property of the model: better LLM, more autonomy. The honest version is the opposite. A weaker model with clean context beats the best model with none. Autonomy is earned through context. It is not shipped in a release.

The dark matter problem

Here is the uncomfortable part. The most valuable knowledge in your organization is not in any system. It is in people’s heads, in corridor conversations, in the unwritten rule that everyone follows and nobody documented.

Call it the dark matter of your organization. You cannot see it, but it holds everything together.

Turning that into machine-readable context is real work. Someone has to sit with your experts, watch how they actually decide, and translate undocumented judgment into something explicit. This is the work nobody wants to do, because it is slow, expensive, and impossible to delegate to a tool. It is also the work that decides whether autonomy is real or theatre.

And there is a problem underneath the problem. You are asking people to write down the very knowledge that makes them feel indispensable. Then you pretend this is a data exercise. It is not. It is the scar at the center of the whole effort, and treating it as a tooling question is how these projects quietly die.

There is nothing off the shelf

You cannot buy a finished context layer. The market is immature, the tools are fragmented, and the mature vendor product does not exist yet. Anyone who tells you otherwise is selling the slide, not the system.

For a large public-sector organization in Germany, in a heavily regulated environment, that turns out to be a feature. The codified knowledge stays in the building. It becomes a sovereign asset you own, not a dependency you rent. Digital sovereignty here is concrete: your context does not stop working because a vendor changed its terms, and your decision logic is not sitting on someone else’s roadmap.

I use international AI models extensively, for learning, prototyping, and strategic evaluation. For regulated data and operational casework, they are off the table. Knowing where to draw that line is the actual leadership skill, not a footnote to it.

What I would do before the next pilot

After four decades in regulated environments, I have watched enough automation projects fail at exactly this point to stop blaming the technology. Before you approve the next agent pilot, put the money into context, not models.

**Name the owners.** Every domain needs a named context owner plus one central curating function. Release through a defined four-eyes procedure, not ad hoc. Knowledge with no owner becomes a silo again.

Fix the incentive. Frame codifying knowledge as a promotion, not a self-erasure. The person who writes down the context becomes the authority over the system, not its replacement. Tacit knowledge is never fully recoverable anyway. The human stays the final decision-maker. Say that out loud and mean it.

Curate one source, not many copies. One concept, one governed definition, versioned, reviewed. Redundancy is how contradictions creep back in.

Protect integrity like security code. Versioning, signatures, audit trails, role-based write access, four-eyes release. Context poisoning is real: feed an agent a false rule and it will execute it with full confidence. Validate dynamic inputs before the agent treats them as truth.

Design for graceful failure. Where the codified context ends, the human takes over on purpose, not by accident.

The agents are coming, and they will do plenty of things better. They will do nothing better for an organization that has never written down what it actually knows. The model is not the hard part. The model was never the hard part.

What is the one piece of knowledge in your organization that lives entirely in one person’s head? Hit reply and tell me. I read every response.

Read the article in german language: https://www.lezgus.de/autonome-ki-agenten-warum-die-kontextlucke-teurer-wird-je-weniger-du-fragst/

Die Zweite Meinung (german blog)

The question is no longer whether you need governance. The question is whether your governance is fast enough to still matter.

Most of CIOs worldwide plan to deploy AI agents in production. The uncomfortable reality: most haven’t translated their governance rules into a format an autonomous agent can understand and follow. They’re planning autonomous systems while steering them with handbooks and quarterly reports.

What happens when governance can’t keep up

An autonomous agent processing data, issuing recommendations, or initiating transactions needs clear boundaries. Not as a PDF in a SharePoint folder. Not as a slide in a steering committee presentation. As version-controlled code that physically prevents an action outside the permitted scope.

I’ve spent years in a large, heavily regulated organization watching what happens when those boundaries don’t exist in machine-readable form. Review boards that meet four times a year routinely delay decisions by six months or longer. A deferral here, a supplementary review there, a referral to another committee the quarter after. While the board deliberates, the technology moves on. The organization stops steering. It reacts. At best. At worst, it doesn’t notice that autonomous systems are already making decisions no committee has ever seen.

Policy-as-Code reverses this logic. Instead of discussing rules in meetings and approving them by resolution, they get deployed as machine-readable logic. Like software: with tests, with versioning, with automatic enforcement in real time.

Concretely: a rule like “no personal data transferred to external interfaces without clearance” stops being a paragraph in a governance document. It becomes a constraint embedded in the agent’s code. The agent cannot cross that boundary because the code physically prevents it. Not because it read the policy. Because the policy is part of its architecture.

The demographic dimension most organizations ignore

In many organizations I’ve worked with, the most important business rules don’t exist in documents. They live in people’s heads. Passed along in hallway conversations, refined in informal discussions, explained over coffee. The colleague who has known for thirty years which data categories must never go to external systems has never written it down. She didn’t need to. She was always there.

In five years, she’ll be retired. None of that knowledge is machine-readable. None of it survives the generational transition unless someone captures it in a form an autonomous system can interpret. This isn’t an abstract risk. It’s a concrete knowledge loss already priced into the age structures of many organizations.

Three things you can do this week

Start with three rules, not thirty. Identify the three governance rules whose violation would cause the most damage. Access rights to critical data, budget limits for autonomous procurements, classification rules for sensitive information. Code them as machine-readable constraints. Three working rules matter more than three hundred documented ones.

Create the role of the governance engineer. Someone who writes governance rules as code, reviews them, deploys them into the agent environment. The experienced staff bring domain knowledge. The younger colleagues bring the technical implementation. Neither replaces the other.

Make the governance auditable. Every change to a governance rule gets versioned. Who changed what, when, and why? In regulated environments, this traceability isn’t a nice-to-have. It’s an obligation that coded rules make easier to fulfill than any document-based governance ever could.

The biggest hurdle isn’t the technology. It’s the culture. Most governance teams see themselves as gatekeepers. Policy-as-Code demands the opposite: not “no,” but “yes, within these boundaries.” From preventer to enabler. That sounds like a nuance. In practice, it’s a paradigm shift that touches the self-image of entire departments.

I’ve caught myself underestimating that shift. The hard part isn’t writing the code. It never was.

If this resonates -- or if you’d push back on any of it -- I’d genuinely like to hear it. Hit reply.

Read the article in german language: https://www.lezgus.de/ki-governance-als-code-warum-richtlinien-autonome-agenten-nicht-aufhalten/

Die Zweite Meinung (german blog)

Most organizations invest in sovereign infrastructure - then sign contracts that undermine it.

Contracts, jurisdictions, subcontractors, acquisitions. Four words that rarely appear in sovereignty debates - and yet they determine whether your organization can still act independently tomorrow. Everyone talks about sovereign cloud infrastructure. Almost nobody talks about the contracts that are supposed to protect it.

I’ve spent four decades in a national law enforcement agency. For most of that time, I believed sovereignty was primarily a technical question: Where are the servers? Who controls the encryption keys? Who has root access? These questions matter. But they’re not enough.

The real vulnerability sits in the fine print.

The problem nobody discusses

The sovereignty debate focuses on data centers, open-source alternatives, and European cloud providers. That’s not wrong. But it’s incomplete.

Your technical infrastructure is only as sovereign as the contract governing it. In regulated environments, I see the same pattern repeatedly: organizations invest heavily in sovereign infrastructure and then sign contracts with no mechanism to verify data residency, no control over subcontractor changes, and no realistic exit path. The contract says “data stays in your Country.” Whether that’s true, nobody knows. Because nobody checks.

This problem has gained a new dimension. In the AI space, innovative startups are being acquired at breathtaking speed by other Country corporations. Your contract partner from yesterday belongs to a company operating under an entirely different legal framework tomorrow. And your contract? Has no clause for this scenario. Your data is there anyway.

This isn’t a future risk. It’s a present condition.

Five levels of contractual sovereignty

Most organizations believe their contracts protect them. An honest maturity model reveals where you actually stand.

Level 1 - Implicit. Sovereignty is assumed but never contractually defined. Your provider stores data “somewhere in the geopolitical restriction.” You trust that. Until you can’t.

Level 2 - Reactive. Standard clauses from provider boilerplate. Data residency appears somewhere on page 47 of the terms and conditions. No monitoring. Compliance is assumed until an incident proves otherwise. The difference from Level 1 is cosmetic.

Level 3 - Defined. This is where real sovereignty begins. Custom clauses become part of the contract: data residency with specific locations, subcontractor transparency with approval requirements, exit mechanisms with defined timelines and data portability guarantees. Verification through periodic audits - manual, but systematic. The critical difference: someone actually checks whether the contract is being honored.

Level 4 - Managed. Sovereignty controls are actively and continuously enforced. Dashboards show compliance status. Third-party risk assessments are integrated. Geopolitical risk evaluation is a standing agenda item in vendor reviews - not as a formality, but as an early warning system.

Level 5 - Dynamic. Automated monitoring of all contractual sovereignty obligations. Changes in legal jurisdictions or corporate structures are detected and trigger defined escalation processes. The organization doesn’t react to incidents. It recognizes shifts before they become incidents.

The jump from Level 2 to Level 3 is the most critical. It requires no new technology. It requires a decision: Do we want to enforce our sovereignty contractually - or just document it?

Most organizations I know operate at Level 1 or 2. They have contracts with sovereignty references, but no contracts with sovereignty effect.

Who governs when the contract is silent?

A good contract alone isn’t enough. Without active governance, it’s a statement of intent, not a shield.

Contractual sovereignty needs clear responsibilities across the organization. Four tasks that someone must own concretely: defining and updating sovereignty requirements, continuous monitoring of contract compliance, geopolitical risk assessment with impact analysis on existing contracts, and incident response for sovereignty violations.

In regulated environments, I regularly see that none of these tasks are assigned to a specific team. IT thinks Legal handles it. Legal thinks Procurement covered it in the contract. Procurement thinks IT monitors it. Nobody monitors.

The result: the first contact with reality happens when the damage is already done.

Here’s a simple test. In your next meeting, ask who is responsible for monitoring the sovereignty clauses in your IT contracts. If the answer takes longer than three seconds, you have your answer.

Four red flags in your contracts

Before you start a major overhaul, check your existing contracts for these warning signs.

No exit without pain. Your contract contains no clear exit clauses. No defined migration path, no data portability guarantee, no realistic transition period. You’re technically sovereign but contractually trapped. Your provider knows it.

Subcontractors in the fog. You don’t know which subcontractors your provider uses - or you find out after the change is complete. No approval requirement, no advance notification, no control over which jurisdiction actually processes your data.

Change of control without protection. Your contract has no change-of-control clause. When your AI startup is acquired by am other corporation tomorrow, contractually nothing changes. Practically, everything does - legal jurisdiction, data access rights, business policies, willingness to cooperate. The consolidation wave in the AI market makes this not a question of possibility but of timing.

Compliance on trust. Your contract prescribes data residency but contains no verification mechanism. No audit rights, no transparency reports, no technical verification. You hope the provider complies. That’s not risk management. That’s faith.

What you can do this week

Three measures that require no major restructuring but have immediate impact.

First: Take your most critical IT contracts and check them against the four red flags above. Start with contracts where personal or security-relevant data flows. One week is enough for the initial assessment. After that, you’ll know where you stand - which is more than most organizations can claim.

Second: Develop modular contract components -- standardized sovereignty modules for data residency, subcontractor governance, change of control, and exit management. Not new framework contracts. Supplements that can be built into existing contracts. One component that’s often forgotten: mandatory prior written approval for every offshore subcontractor change.

Third: Put IT, Legal, Procurement, and Information Security at one table. Not as a project group with an expiration date, but as a permanent body with a clear mandate: sovereignty monitoring, escalation, contract adaptation. With named individuals, not role descriptions that everyone interprets differently.

One note on a distinction that belongs in every contract: for exploration, prototyping, and evaluation, I use international AI models extensively. For regulated data and operational law enforcement work, they’re out of the question. This distinction must be contractually specified. Explicitly, not as an implicit assumption.

Your contract is your sovereignty level. Not your data center. Not your strategy paper. Your contract.

If you’ve done the three-second test in your own organization - I’d genuinely like to hear what happened. Hit reply.

Nobody asked what happens to the 340 people currently doing that work.

Agentic AI isn’t a chatbot upgrade. It’s an architecture where systems independently plan their approach, select tools, reflect on results, and adjust course. Large financial institutions already use autonomous agents for credit assessments. Consumer goods companies let AI systems orchestrate marketing campaigns — pulling data, segmenting audiences, reallocating budgets — without a human approving each step.

This isn’t incremental change. It’s structural. And in my experience running technology for a 7,000-person federal security organization, three effects are converging that most leadership teams haven’t fully reckoned with.

Self-organizing workflows change what leadership means

Here’s the shift most leaders miss: you’re no longer managing processes. You’re managing goal definitions and guardrails.

An agent receives an objective, decomposes it into tasks, selects appropriate tools, executes, and self-corrects when intermediate results don’t match expectations. In practice: it searches a database, evaluates results against defined criteria, pulls a second source if needed, and produces a report. All in real time. All dynamically adapting.

The question is no longer “who does what.” It’s “what outcomes do I expect, and what boundaries do I set?”

In heavily regulated environments — law enforcement, healthcare, financial services — this creates a particular tension. Governance here means auditable decision chains, revision-proof documentation, clear accountability. An agent that finds its own path must meet those requirements just as rigorously as the case officer on the fourth floor. If it doesn’t, you haven’t gained efficiency. You’ve gained legal liability.

The digital workforce isn’t a metaphor anymore

This is the uncomfortable part. Agentic AI creates a digital workforce. Not figuratively. Operationally.

An agent is goal-oriented. It receives a task, pursues it to completion, reports back. Multiple agents coordinate, assign subtasks to each other, consolidate results. That’s not accidentally similar to a team. It functions like one.

The question leaders need to ask: if three coordinated agents complete in 20 minutes the same research task that took four people two weeks — what follows?

Here’s where I see organizations making a dangerous mistake: they plan agentic AI only as augmentation. A tool that supports existing teams. But the technology compresses experience. What previously required seniority — forming coherent pictures from fragmented information — a well-orchestrated agent system can partially replicate.

This doesn’t make people redundant. But it shifts which competencies matter. Tomorrow’s workforce configures agents, evaluates their outputs, and handles the exceptions no algorithm can resolve. That’s potentially a gain. But only if the organization designs this transition deliberately.

Three strategic options: reposition people into new roles that agentic AI creates. Limit deployment to defined areas, protecting human expertise where it’s irreplaceable. Or acknowledge that in some areas, the digital workforce will absorb capacity gaps from demographic change. Most organizations will need all three simultaneously.

When machines prepare decisions nobody questions

This is the most consequential shift. Agentic AI doesn’t just prepare decisions. In certain contexts, it makes them.

Autonomy levels are the key. At the lower end: advisory agents that collect information and present options. A human decides. At the upper end: fully autonomous agents that analyze, evaluate, decide, and act. Reality lives in the spectrum between.

The temptation is obvious: if the agent was correct in 98% of the first 500 credit decisions, why keep the human sign-off? The answer, for anyone who’s worked in regulated environments: because the 2% errors aren’t randomly distributed. They cluster in complex, ambiguous, context-sensitive cases. The ones that affect lives.

What leaders need now is a differentiated governance model for decision autonomy. Not one model for the entire organization — but a clear matrix: which decisions can an agent make autonomously? Where must a human approve? Where shouldn’t the agent even recommend?

From my experience deploying multiple AI systems in a large federal agency: building this differentiation takes time. Significant time. But it’s the foundation that prevents agentic AI from becoming a legal and reputational risk.

What you can do this quarter

Four areas deserve immediate attention:

Governance before technology. Before deploying your first agent, establish the rulebook. Which decisions may be automated? Who’s liable when an agent is wrong? How do you ensure traceability? These questions protect you from the moment an autonomous process makes a decision you can’t explain.

The technology will evolve in the next 12 months. Your governance must keep pace. That requires not just technical competence — it requires organizational learning capacity.

And that, ultimately, is the real leadership challenge.

This stopped me. Because in most strategy conversations I witness, the budget discussion starts with: Which tool should we buy? Not: Is our data in a state that any tool could actually work with?

The Real Bottleneck

Here is what I have learned from decades in a highly regulated government environment: the bottleneck is never the model. The bottleneck is context.

A structured context layer — semantic mappings, ontologies, machine-readable rules — reduces the computational cost of reasoning models by a factor of two to three. Same accuracy. Lower cost. Context is simultaneously a quality lever and an efficiency lever. Yet almost no one treats it as infrastructure.

In my domain, this is not optional. Without semantic labeling of individual data points, analysis is constitutionally prohibited. No labeling, no analysis. Full stop. This is not a bureaucratic inconvenience. It is a design constraint that determines everything else.

But here is the transferable insight: every organization working with sensitive data faces the same fundamental question. Do you invest in the tool, or in the foundation the tool needs to stand on?

The Cautious Paradox

There is a popular framework that classifies organizations as AI-first, AI-opportunistic, or AI-cautious — and then declares the cautious position a high-risk one by 2030.

I disagree. Or rather: I think the classification is too blunt.

The real dividing line runs between cautious-without-foundation and cautious-with-foundation. An organization that deliberately delays tool deployment while building its context layer, governance architecture, and semantic infrastructure is not at risk. It is preparing.

An organization that is cautious AND idle — that is a different story entirely.

Caution without preparation is paralysis. Caution with preparation is strategy.

Three Things Worth Doing Now

A Question for You

I am curious: does your organization distinguish between being cautious and being unprepared? Or does the strategy conversation collapse both into the same bucket?

Hit reply. I read every response.

— Andreas

Read the article in german language: https://www.lezgus.de/ki-kontext-als-kritische-infrastruktur-warum-deine-datenstrategie-ein-fundament-problem-hat/

Die Zweite Meinung (german blog)

So when industry analysts predict that 75 percent of all data engineering workflows will be automated by AI agents by 2029, I don’t feel excitement. I feel a very specific kind of concern. The kind you develop after watching three decades of automation promises crash into the same wall.

That wall has a name. It’s called: we don’t actually know what data we have.

The promise sounds familiar

The current trajectory is clear: we’re heading toward a world where autonomous agents build pipelines, monitor data quality in real time, enforce governance rules, and self-heal when something breaks. Three types of agents are supposed to work together: specialized task agents for cleaning and transformation, orchestration agents coordinating across systems, and multi-agent systems that learn and optimize the whole thing.

The architecture is sound. The vision is compelling. And if you’ve been dealing with manual data pipeline maintenance for years, the appeal is immediate.

Here’s what the vision quietly assumes: that your organization already has a semantic layer. Machine-readable business definitions. A data catalog that reflects reality. Clear ownership for every data domain. Governance rules that are documented, not tribal knowledge.

In my experience, most organizations have none of this. Not partially. Not in rough form. Simply not at all.

What happens without the foundation

I’ve seen this pattern more than once: a large organization launches a data quality initiative with the best intentions. Identify problems systematically, measure them, fix them. Automated rules, clear metrics, repeatable processes.

The project stalls before it properly begins. Not because the technology fails — but because nobody can answer the most basic question: what data do we actually have, where does it live, and what does it mean?

There was no data catalog. No machine-readable definitions. No clear ownership. The quality rules had nothing to attach to. The team had to step back and inventory before they could measure. It sounds almost embarrassingly simple. That’s precisely why it matters.

Now imagine what happens when you skip that step entirely and deploy an autonomous agent instead. An agent that classifies data as non-sensitive when it doesn’t understand the classification scheme. An agent that restructures a pipeline because its model detected an anomaly that wasn’t one. An agent that adjusts access permissions based on patterns it inferred from inconsistent metadata.

In a hospital, that could mean patient records exposed to the wrong department. In financial services, regulatory violations. In law enforcement, where I’ve spent my career, it could mean classified information flowing into unclassified systems. These aren’t theoretical risks. They’re the predictable consequence of deploying autonomous decision-making on a foundation that doesn’t exist.

The real problem isn’t speed

Every automation wave I’ve lived through started with the same diagnosis: too much manual work, not enough speed. ETL tools were supposed to eliminate manual transformation. Self-service BI was going to free analysts from IT dependencies. DataOps promised to unify development and operations. Each time, the prescription was the same. Automate more. Move faster.

Each time, the organizations that struggled weren’t struggling with speed. They were struggling with understanding. They didn’t know what their data meant, who was responsible for it, or what “correct” looked like. More automation didn’t solve that. It amplified it.

AI agents are the most powerful amplifier yet. A rule-based system that runs on bad metadata produces one bad report. An autonomous agent running on the same bad metadata makes a thousand bad decisions per hour. And it makes them with a confidence no human would have, because it lacks the awareness of its own blind spots.

The question isn’t “which agent platform should we buy?” The question is: “Do we know our data well enough to trust an agent with it?”

For most organizations I’ve worked with, the honest answer is no.

Three things before your first agent

This isn’t about saying no to AI agents. They will transform data management, and they should. But the sequence matters, and it can’t be shortcut.

And one more thing that rarely makes it into the vendor presentation: metadata sovereignty. Who owns the business definitions and classifications your agent processes on a cloud platform? That question feels abstract until the vendor changes their API or discontinues the service. For organizations in Europe operating under strict data sovereignty rules, this isn’t a theoretical concern. It’s a strategic decision you make today whose consequences surface three years from now.

The uncomfortable truth

The organizations that will benefit most from AI agents in data management are the ones that need them least right now. They’ve done the unglamorous groundwork. They know their data. They have governance that works before it’s automated.

For everyone else, the path isn’t shorter because the tools got smarter. It’s the same three steps: know your data, organize your data, then automate. No agent makes the first step unnecessary.

The hard part isn’t the technology. It never was.

If you’re navigating this in your own organization, I’d like to hear how it’s going. What’s the biggest gap you’re seeing between the agent promise and your data reality? Hit reply.

I also write in-depth analysis in German on my blog: www.lezgus.de

Read the article in german language: https://www.lezgus.de/agentic-ai-im-datenmanagement-was-du-brauchst-bevor-der-erste-agent-startet/

Die Zweite Meinung (german blog)

Nearly 60% of organizations have evidence of unsanctioned AI agents operating in their environment. At the same time, vendors are slapping the label “AI agent” on everything from basic workflow automation to traditional machine learning. The result is a gold rush mentality colliding with organizations that are nowhere near ready for it.

But this is only one of three fault lines I see forming right now. And the dangerous part is not any single one of them. It is how they reinforce each other.

Fault line one: AI agents outpace regulation

Governments worldwide are tying their AI ambitions to agents. Conversational service experiences, autonomous decision support, citizen-facing automation – the use cases multiply faster than the governance frameworks.

Here is the uncomfortable truth: 62% of surveyed organizations believe AI agents should only be created by IT departments, not end users. Only 15% are even considering fully autonomous agents. Yet the deployment keeps accelerating.

The gap between ambition and control creates real risk. When an underregulated AI agent makes a mistake in a citizen interaction, the vendor does not lose credibility. The government does. And in the public sector, trust is not a soft metric. It is the operating license.

By 2029, an estimated 20% of government service failures will trace back to underregulated AI agent interactions. That is not a theoretical warning. It is a predictable consequence of moving faster than your governance can follow.

The question nobody asks in the meeting: “Is this actually an AI agent – or rebranded automation we already have?”

Fault line two: sovereignty as strategic illusion

Digital sovereignty has become a political priority in nearly every region. But current estimates suggest that by 2028, 60% of government sovereignty initiatives will miss their objectives. The culprit: unrealistic timelines and investment estimates driven by political cycles rather than technical reality.

Most sovereignty efforts focus narrowly on data residency and basic cloud services. The deeper risks across entire technology stacks – from workplace tools to AI platforms to SaaS applications – remain invisible.

I call this **sovereignty washing**: local providers promise sovereign solutions on their websites while relying on hyperscalers in their supply chains. The dependency is just hidden one layer deeper.

Digital sovereignty is not a project you complete in one budget year. It is a strategic posture that takes years to build. Leaders who treat it as a checkbox exercise will waste money and political capital without reducing actual risk.

Fault line three: vibe coding creates invisible debt

Here is the fault line that gets the least attention: vibe coding. The concept of creating applications through natural language prompts – without writing traditional code – is gaining traction fast. 72% of surveyed government organizations plan to increase their application modernization budgets. 46% already use low-code platforms. Vibe coding is the logical next step.

For prototypes and innovation labs, this makes sense. The danger lies in the creep from experiment to production.

A vibe-coded prototype works for the demo. But it knows nothing about architectural standards, security policies, or integration requirements. When budget pressure and short election cycles push that prototype into production, you create technical debt that takes years to unwind.

By 2028, an estimated 75% of governments without vibe coding controls will rank architectural technical debt as their biggest modernization challenge.

Where the three fault lines meet

Here is what keeps me up at night: these three trends are not independent. They converge.

An unregulated AI agent running on a non-sovereign platform, built with vibe coding and no architectural oversight – this is not a hypothetical scenario. It is the direction of the current trend.

The role of government CIOs is shifting from technology stewards to strategic risk managers. Success depends on balancing innovation with resilience and building local ecosystems that mitigate foreign technology dependencies.

The path forward

We can address these fault lines. Not through panic. Not through blanket rejection of new technology. Through deliberate governance.

For AI agents: Deploy preventive risk assessments before any agent goes into production. Demand transparency, observability, and manual fallback mechanisms from every vendor. Existing automation solutions already in your cloud may achieve the same results with far less risk.

For sovereignty: Map direct and indirect foreign dependencies across your core technology stacks. Prioritize by risk, cost, and strategic value. The goal is rarely full decoupling. It is maintaining the ability to act in a crisis.

For vibe coding: Limit current use to non-critical experiments. Adjust your software development lifecycle to specifically address vibe coding risks. Require human review and architectural sign-off before any production deployment.

Before you close this tab – here is your practical takeaway.

✅ Audit your organization for unsanctioned AI agents – the number will likely surprise you

✅ Ask every AI vendor: “Is this genuinely agentic, or rebranded automation we already own?”

✅ Map your supply chain dependencies at least two levels deep – sovereignty washing hides there

✅ Define clear boundaries for vibe coding: what may be prototyped, what requires architectural review

✅ Require human sign-off before any AI-generated application enters production

✅ Add a quarterly technical debt review to your IT steering committee agenda

✅ Create a sovereignty register documenting where your data actually resides – not where it should

If this gave you one idea worth testing – consider subscribing. I publish weekly with practical frameworks for AI leaders who need clarity, not hype.

Subscribe now

What is the biggest blind spot in your organization’s AI strategy right now? I am genuinely curious – your experience helps me write better frameworks for everyone.

Leave a comment

I also write in-depth analysis in German on my blog: www.lezgus.de

I’ve lived this paradox for years as a CTO in one of Germany’s most security-sensitive federal agencies. The tension between innovation speed and institutional control isn’t new. But with AI, it’s sharper than ever. And the organizations that don’t resolve it will find themselves stuck between two equally dangerous outcomes: paralysis or chaos.

The question isn’t whether your people will experiment. They already are. The question is whether you’ve given them a safe lane — or forced them into the shadows.

The gatekeeper trap

Here’s what happens in most large organizations. A team identifies a promising AI use case. They build a prototype. Then they hit the governance wall: no approved tools, no reference architecture, no clear path to production. The pilot stalls. Meanwhile, three other teams quietly spin up their own solutions using whatever SaaS tool has the friendliest onboarding flow.

This is AI sprawl. And it’s the predictable result of governance that says “no” without offering an alternative.

Heads of Enterprise Architecture are uniquely positioned to break this cycle. Not by loosening standards, but by creating reusable pathways — clear architectural blueprints that make it easier to do the right thing than the wrong thing.

This is a mindset shift. From blocking unapproved initiatives to enabling approved ones. From reviewing every request to publishing a catalog of pre-validated patterns. How many of your teams could start an AI pilot tomorrow using only approved tools and documented patterns? If the answer is “none,” your architecture isn’t enabling anything.

Build the blueprint before the pressure hits

The first concrete step: create an AI reference architecture grounded in both business strategy and technical reality. That blueprint should define common use cases, approved technology stacks, deployment patterns for cloud and on-premises environments, and security controls with privacy requirements baked in.

In my experience, the organizations that move fastest are those that did this work before the first AI pilot landed on the CTO’s desk. The ones that scramble to build governance after a dozen pilots are already running? They end up with a patchwork of contradictory rules and frustrated teams.

A solid approach follows roughly ten steps — from understanding your strategic context and defining AI principles, through building your technology reference model and standards, all the way to designing your decision tree for when to build, buy, or partner. But here’s what matters most: you don’t need perfection. You need a first version.

A reference architecture that covers 80% of common scenarios and ships in four weeks beats a comprehensive framework that takes eight months. Start with your most frequent use cases. Add guardrails for data privacy and model deployment. Publish it. Iterate.

Security isn’t a phase — it’s a foundation

Security controls must be designed from the outset, not retrofitted. This sounds obvious. In practice, I’ve seen it ignored more often than followed.

Every AI system should undergo threat modeling before deployment. Frameworks like MITRE ATLAS (purpose-built for AI and machine learning threats) and the NIST AI Risk Management Framework are solid starting points. OWASP’s Top 10 for LLM Applications and ENISA’s AI Threat Landscape add useful depth. But the framework matters less than the discipline of actually doing the assessment — and doing it early enough to influence design decisions.

What deserves more attention is data governance. The quality and security of training data is where many AI projects silently fail. Architecture teams should work closely with data and analytics stakeholders to identify and prepare datasets before experimentation begins. Waiting until a model is half-trained to discover the data violates privacy regulations is an expensive lesson. I’ve watched organizations learn it the hard way.

One promising development for regulated environments: synthetic data — machine-generated datasets that mimic real-world scenarios without exposing sensitive production data. It can accelerate experimentation significantly, provided strict boundaries between sandbox and production environments are maintained.

And then there’s shadow AI — the unsanctioned use of AI tools that bypass every policy you’ve written. Without strong governance, shadow AI introduces data breaches, regulatory violations, and unintended bias. The principle of least privilege isn’t just a security concept here. It’s a governance survival strategy.

Your AI agents need identity cards

Here’s a blind spot that too few architecture teams address: identity and access management for AI systems.

Traditional IAM was designed for humans. Log in, get a role, access resources. But AI agents don’t log in. They operate autonomously, often on behalf of users, sometimes chaining actions across multiple systems. If you don’t assign a clear identity to every AI agent and service account — with traceable ownership back to a responsible human — you’ve built a compliance nightmare.

What’s needed: robust authentication using tokens or certificates, fine-grained authorization based on least privilege, and comprehensive logging of every action. In regulated industries, every action an AI agent takes must be auditable. Every delegation of authority must be traceable.

Credential lifecycle management matters too. Automated provisioning, rotation, and deprovisioning of machine credentials sounds like plumbing. It is plumbing. And when the plumbing fails, the flood reaches the boardroom.

Governance needs people, not just policies

The final piece — and perhaps the most underestimated — is cross-functional collaboration. An AI governance forum should bring together enterprise architecture, legal, security, data science, product management, and executive leadership. With real decision authority. Not advisory status.

I’d add a warning from experience: these forums only work if they meet regularly and have teeth. I’ve seen too many “AI boards” that convene quarterly, rubber-stamp decisions made months earlier, and wonder why shadow AI keeps spreading.

What works better: tight feedback loops. Daily stand-ups during critical implementation phases. Retrospectives after each pilot. Legal advisors who review data handling during design, not after launch. Security experts who validate controls before deployment, not in the incident report.

The Head of EA should be the orchestrator — not the sole decision-maker, but the person who ensures the right stakeholders are in the room at the right time. When legal, security, data, and business teams operate in silos, AI governance becomes a bureaucratic exercise. When they collaborate early and continuously, it becomes a competitive advantage.

The real question behind all of this

The four pillars — standardized architecture, security-first controls, AI-specific identity management, and cross-functional governance — cover the essential ground. But frameworks don’t transform organizations. Execution does.

The deeper question for every Head of EA reading this: are you enabling experimentation, or are you just managing risk on paper?

If your teams can’t go from AI idea to approved pilot in under four weeks, your architecture isn’t enabling anything. If no one knows which tools are approved for which use cases, your governance exists only in documents. If your AI agents don’t have registered identities, your security posture has a gap that grows with every new deployment.

The organizations that will lead in AI aren’t the ones with the most sophisticated frameworks. They’re the ones where the architecture team made it easy to experiment safely. And that, in my experience, is the hardest thing to get right — not because it’s technically complex, but because it requires letting go of the gatekeeper role that made us feel important in the first place.

Before you close this tab — here’s your practical takeaway.

✅ Publish a first-version AI reference architecture within 30 days — cover your top 3 use cases, approved stacks, and security baselines. Perfection later, momentum now.

✅ Inventory every AI tool and agent currently in use across your organization — you can’t govern what you can’t see.

✅ Mandate threat modeling for all AI initiatives before deployment, using MITRE ATLAS or NIST as your starting framework.

✅ Register every AI agent and service account with a named human owner — no orphaned machine identities.

✅ Establish an AI governance forum that meets at least biweekly with actual decision authority — not a quarterly rubber-stamp committee.

✅ Prepare curated, validated datasets for experimentation before teams ask for them — proactive data governance beats reactive firefighting.

✅ Measure your time-to-approved-pilot — if it’s longer than four weeks, your architecture is a bottleneck, not an enabler.

If this gave you one idea worth testing — consider subscribing. I publish weekly with practical frameworks for AI leaders who need clarity, not hype.

Subscribe now

Have you found a way to balance speed and security in AI experimentation that actually works — or is your organization still stuck between "block everything" and "hope for the best"? Let me know in the comments.

Leave a comment

I also write in-depth analysis in German on my blog: www.lezgus.de