I joined a German enterprise and finally understood what AI governance actually means

The Culture Shock

Before joining my current employer - a subsidiary of a large German company in the energy sector - I had spent years in startups and small agencies. "Move fast and break things" was not just a motto, it was the operating system. Ship on Friday, fix on Monday, apologize if needed.

My first week at the new company ended that worldview permanently.

I was debugging a Symfony controller and wanted to ask Claude about an edge case. Standard practice at my previous jobs. I opened the browser, started pasting the code, and my colleague Markus - a senior developer who had been with the company for eleven years - reached across the desk and closed my laptop lid.

"We do not do that here," he said. Not angry. Just matter-of-fact, like telling me the coffee machine was broken.

"Why not?" I asked, genuinely confused.

"Because that controller handles asset fault data for energy infrastructure. If that data ends up in a training set, we have a compliance problem that goes all the way to Berlin."

He was right. And that moment changed how I think about AI forever.

Understanding What Is At Stake

The company builds software for managing physical assets in the energy sector. When a piece of equipment breaks down - a transformer, a pipeline valve, a distribution node - a ticket opens in our system. It gets classified, assigned, tracked, and resolved. The data includes equipment specifications, location data, maintenance histories, and sometimes information that could be classified as critical infrastructure.

This is not a social media app where a data leak means embarrassing photos. This is infrastructure data where a breach could have physical-world consequences. The German legal framework around this is not a suggestion - it is the law, enforced with real penalties.

The Request (And the Resistance)

During my first weeks, management asked the engineering team to "explore AI integration." They had seen the productivity gains reported by other companies. They wanted the same.

The developers were excited. GitHub Copilot, ChatGPT, Claude - finally, the tools everyone else was using. The legal department was less enthused. Their response was a fourteen-page memo explaining every way AI tools could violate GDPR, the EU AI Act, and internal data classification policies.

Both sides were right. The developers needed modern tools to stay competitive. Legal needed to protect the company from existential compliance risk. Someone had to bridge the gap.

That someone ended up being me.

What came out of those early conversations was an internal AI board - legal, compliance, engineering management - that would own AI policy going forward and approve every tool that entered the company. My role was on the engineering side of the bridge: showing the team how AI coding assistants actually work, building the technical guardrails the board's policy required, and reality-testing what could and could not safely enter our workflow.

Building the Framework

The AI board owned the policy. I owned the technical layer that made the policy usable - showing the team how the tools work, where they are safe, and building the guardrails the board needed to see in place. Three months of meetings, drafts, reviews, and compromises, and we landed on this:

AI Usage Policy (drafted by the AI board). A specific, detailed document that answers questions developers actually have: which tools are approved, what data can go through them, what happens if you accidentally paste something sensitive, how to report an incident. My contribution was the technical reality check - which workflows developers actually use, where the friction will be, what guardrails the policy needs to mandate. Every developer reads the final version, signs it, and gets a refresher quarterly.

.aiignore Configuration. We adopted a system modeled on .gitignore but for AI tools. It is part of the AI tooling ecosystem, not something I built from scratch, but I configured it extensively for our codebase. Certain directories, file patterns, and even code patterns are automatically excluded from AI context. Configuration files with connection strings? Excluded. Modules that handle customer data? Excluded. Migration files with database schemas? Excluded. The AI tools literally cannot see the sensitive parts of the codebase.

Data Censoring Pipeline. For situations where developers need AI help with sensitive code patterns, I built a preprocessing step. Before code leaves the network, a script redacts sensitive values while preserving structure. Variable names stay (they are needed for context), but values get masked. Connection strings become placeholders. API keys become [REDACTED]. The AI sees the pattern without the data.

Data Residency for Sensitive Code. For the most sensitive operations - production logs, security-critical code, anything touching personal data - the data stays inside the company network with data-residency controls and audit trails. AI tooling for these categories is allowed only after explicit review. Full local LLM deployment on company hardware is something I have set up before for customers in regulated industries; here, it is being considered for the highest-risk operations where even the censoring pipeline would not be enough.

The Shared Configuration

Once the AI board's policy was in place and the technical guardrails agreed on, I built the tools that would enforce them daily. A shared configuration for our AI coding agents - Claude Code and Codex - that the development team can install. It includes fifteen custom skills I wrote specifically for our workflow:

Jira integration that pulls ticket context without exposing customer data. Bitbucket and Gitea PR workflows that enforce commit conventions and branch naming. Confluence access for documentation lookup. Outlook integration for scheduling. Laravel, Symfony, WordPress, and Vue development workflows with automated worktree management for parallel tasks. PHP testing and the BaseService pattern reference for quality. A local CI/CD orchestrator, cross-session memory, a daily work assistant, and a config backup tool round it out.

Four specialized sub-agents that handle common tasks: one for parallel worktree management (so agents can work on multiple Jira tickets simultaneously), one for code simplification and refactoring, one for fast codebase exploration, and one for research that can search the web without exposing internal context.

The result: every developer has the same guardrails, the same integrations, the same workflow. AI-assisted development that legal signed off on.

What Changed

Development velocity increased. That was expected. But the more important change was cultural. Developers stopped seeing compliance as an obstacle and started seeing it as a feature. "Our AI workflow is GDPR-compliant" became a point of pride, not a burden.

The legal team went from blocking AI adoption to actively participating in improving the framework. They started asking technical questions. We started asking legal questions. The wall between departments got thinner.

The Lesson I Carry Forward

This experience fundamentally rewired how I think about AI adoption. Before this role, I would have started any AI project with "which model should we use?" The AI board here taught me to start with three different questions instead:

What data do you have? What are the rules around that data? And who gets fired if those rules are broken?

Speed is not the only metric that matters. Responsibility, traceability, and compliance are not obstacles to innovation. They are prerequisites for sustainable innovation. The companies that understand this will still be here in ten years. The ones that do not will be cautionary tales in compliance textbooks.

The best AI governance does not slow teams down. It gives them confidence to move faster, because they know the guardrails are real.