A company can have a mature compliance program, a software development lifecycle followed by everyone in DevOps, Product, IT, and Engineering, and still have a growing compliance hole.
The controls didn’t necessarily get worse. AI changed who can build, and the world changed underneath the controls.
For a long time, most consequential software passed through Product and Engineering. That meant it also passed through the places where security reviews, change management, vulnerability scanning, access controls, and the rest of the compliance machinery lived. Those controls were embedded as a core part of the software development lifecycle (SDLC).
In Tech, the SDLC is just how we build software. For Compliance, it was also how its requirements and processes reached the software being built. I sit on both sides of that. As a CTPO also overseeing compliance, I’m encouraging people across the company to build, and I’m also usually the executive who has to explain to an auditor, regulator, or customer how that software is controlled — even when Technology didn’t build it.
The SDLC Was Doing More Compliance Work Than We Thought
Most compliance programs were designed around predictable insertion points.
If production software came from Engineering, you knew roughly where to look for it. You could require pull requests, security reviews, approved infrastructure, dependency scanning, access controls, deployment records, change management, and documentation because almost everything that mattered eventually passed through systems where those requirements could be applied. It also made validation for certifications like ISO and SOC straightforward.
The SDLC wasn’t just a development process. It was also a compliance distribution mechanism.
That worked well enough that a lot of the compliance coverage became implicit. Nobody needed a separate organizational, cultural, or technical mechanism to discover that new software existed or was created. The development pipeline did that for you.
Engineering and IT have also accumulated scar tissue around operationalizing software. Dependencies need maintenance, access needs controls, vulnerabilities need tracking, and somebody eventually has to own the thing when alerting fires or fixes are required. When building moves outside those functions, that experience doesn’t automatically follow. It’s easy to miss how much compliance coverage came from that accumulated experience rather than the written process alone.
There Isn’t Always Shadow IT
In If You Want Compliance, Start with Celebration, I argued that you can’t attach governance to work nobody knows exists. The problem sounds obvious, but solving it requires both cultural and technical changes within an organization. If people learn that surfacing what they’ve built gets them told to shut it down, they’ll stop surfacing it. AI can now solve their problem and Compliance is just a speed bump they can also choose to go around. Then you wind up with both an unknown-inventory problem and a compliance problem. Making distributed building visible solves that part.
But visibility isn’t coverage. Visibility only solves discovery.
Someone can post a new customer integration they built in a public Slack channel. They can demo it at an all-hands meeting. The CTO, Head of Compliance, and the entire Technology organization can know it exists.
There would be nothing shadowy (IT) about it.
It can still have no vulnerability-management process, unclear access controls, no audit trail, and nobody accountable for maintaining it. It might even process customer data through a vendor that a specific customer’s DPA (Data Processing Agreement) doesn’t allow if it’s already made it to a customer.
A prototype doesn’t become compliant simply because everyone knows it exists.
This is where I think the traditional framing of “shadow IT” becomes much less useful. Secrecy is not the defining problem anymore. Sometimes the software is standing directly in the light and is still missing the necessary process coverage.
Contracts Still Think You Build Software the Old Way
I wrote about a related problem in Your Company Already Has a Second Operating Model: customer-facing experiments shouldn’t necessarily inherit every production commitment your core SaaS product carries. Different operating models can carry different commitments. For example, support models and SLAs/SLOs can flex with good reason.
But some obligations don’t flex just because the builder has a different job title or experience level.
If you’re processing personal data, the fact that the workflow was built by a CSM using an AI coding agent instead of an engineer doesn’t create a GDPR exemption. The data doesn’t become less regulated because the builder didn’t think of what they were doing as software development.
The same issue applies to the commitments and representations surrounding your software. A customer contract or DPA might restrict how data is processed, what it can be used for, or which sub-processors can be used. A security questionnaire or Trust Center might describe the controls you apply to production software. Then comes a SOC-2 report or ISO certification, which is an independent check on parts of that story. Meaning that someone outside the company looked at the relevant controls rather than simply taking your word that they exist and operate as described.
None of those mean exactly the same thing, and they don’t create the same obligations. But they all depend, in different ways, on there not being a large gap between how the company says software is governed and how software is actually being built.
The exact obligation varies. The underlying issue doesn’t.
Your organization can be saying one thing about how its software is controlled while an increasing amount of actual software never passes through the systems that make those statements true.
That doesn’t automatically make every vibe-coded tool a contractual breach or potential audit finding. It means you can’t assume your existing compliance posture covers software simply because the organization has a compliance posture.
And the discrepancy tends to matter at exactly the wrong types of moments: during an audit, customer security review, incident, insurance claim, or contractual dispute, when somebody asks you to demonstrate that the controls you described actually covered the software involved.
If you’ve contractually represented that certain controls are in place and they weren’t actually applied, a later dispute can become more than just a “technical failure”. It can strengthen a customer’s breach or misrepresentation claim, weaken your ability to defend your position, and potentially trigger contractual remediation, like clawbacks or even termination rights depending on the language of the agreement.
Compliance coverage has to be established, not assumed.
You Can’t Send Everything Back Through Engineering
The tempting response to all this is to recreate the old insertion point: require everything to pass through Product, Engineering, Security, and Compliance before it reaches production.
That isn’t going to work. It won’t work with a mandate and it’s not a cultural change anyone would be willing to accept. There is too much being built in too many places. And Engineering, Security, and Compliance are already constrained resources. More importantly, routing everything back through those teams would remove much of the value that distributed building created in the first place: the people closest to a problem being able to solve it themselves.
So how do you get enough of that expertise to the work without sending all the work back through the experts?
Since you can’t centralize software development again, you have to export compliance.
There is no shortage of tooling trying to help with this. AI has made it cheaper and easier to build increasingly sophisticated compliance and security tools, so more of them are showing up. Many of them are useful if you’re already a compliance or security professional and already understand the underlying concepts. They get harder to use as you move from compliance professionals toward software engineers. And they’re mostly untenable for non-technical builders because the tooling still assumes you know about and understand the problems these tools are trying to help you solve.
Practically, that ends up being the wrong abstraction level for distributed builders. Someone who just vibe-coded a customer workflow shouldn’t need to learn a compliance platform before they can safely ship it. There’s a cultural cost too: putting a compliance training program and some software to learn between someone and the problem they just learned how to solve, is a good way to kill the enthusiasm that made distributed building so attractive to the people that do it.
Exporting compliance doesn’t mean teaching everyone ISO 27001 either (or whatever your organization is subject to). It means moving three things closer to the builder:
- Context: the compliance context the company already knows.
- Recognition: a simple way to recognize when a situation falls outside those defaults and needs expert attention.
- Inherited controls: controls that can be applied automatically without requiring the builder to understand or remember them.
“Make Sure This Is Compliant” Isn’t a Compliance Check
One of the risks here is that the AI agent they’re already building with can look like a substitute for all of that context and expertise. This is where AI can create a particularly dangerous sense of false confidence.
A person who isn’t trained in software engineering or compliance knows enough to know they should probably have their work checked. So they tell their coding agent something like:
Make sure this application is compliant.
Or:
Check this for security and compliance issues.
The intention is good. And if you’re lucky, they may have even heard of OWASP and ask for those checks as a baseline. But the statements above still basically border on meaningless.
Compliant with what? Which controls or customer commitments apply? What data does it touch? Are the deployment environments and vendors approved? What does the company require around access, retention, auditability, and dependencies?
Non-technical builders don’t know to ask those questions. Nor should they know. That’s pretty much the whole problem in a nutshell: they don’t know what they don’t know.
Asking an AI to “make this compliant” without giving it the relevant control set, organizational context, and specific things to assess is the compliance equivalent of a rain dance. I did a rain dance and now I expect it to rain. Cool, you’ve performed an action associated with the outcome you want. That doesn’t mean you caused the outcome if it just so happens to drizzle outside while you’re dancing.
If you tell an agent to “make this secure/compliant” and it comes back after a bunch of work with “looks good,” that isn’t a control if you never defined what secure/compliant means.
Give the Agent the Context Before the Request
But the answer isn’t to stop people from asking their agents to do this kind of work. That instinct is exactly what we want to positively reinforce. The problem is that the agent is being asked to make a decision without the context needed to make it.
It’s the same routing failure I wrote about in You Can Only Push Decisions as Far Down as Context Travels: we pushed the authority to build outward, but much of the compliance context needed to use that authority responsibly, stayed with Compliance.
That context needs a predictable home that a builder’s agent can load. Which vendors and sub-processors are approved? Where is software allowed to run? How is data classified? What does the company expect around dependencies, access, auditability, and retention? Depending on the company, some of those answers may even vary by customer.
If the context is defined, then “check this for compliance” at least becomes a question with a defined problem behind it.
This doesn’t have to be an exhaustive set of requirements before it’s useful. Start with what the company already knows and improve it as new cases surface. A partial set of explicit rules is still better than asking an agent to infer all of this from nothing.
I’m painfully aware that all this is easier said than done. The harder problem is keeping that context current and making sure it actually gets used. Customers’ DPAs differ. Dependencies become vulnerable. Someone has to own all that context as an operational asset, and keeping it current is likely to be non-trivial recurring work. Make sure you operationally budget for it like any other system you maintain.
And a context package nobody loads is just another wiki page going stale. The most useful version of this is the documentation (hopefully) already wired into the templates and tools that builders reach for.
Recognize When the Defaults Aren’t Enough
Compliance context covers what the company already knows. The builder and their agent still need to recognize when something falls outside those defaults and requires expert insight.
I find it easier to assess the software’s capability than the builder’s understanding of the software.
3 Capability Tripwires
Three questions should be enough to tell you when Compliance may need to get involved:
- Data Access: What sensitive systems or data can it access?
- Untrusted Input: What external or untrusted input can influence it?
- Autonomous Action: What can it do without a human approving the action?
Any one of these deserves attention when answered “positively”. The combinations are where the risk can change dramatically. An agent consuming untrusted input with write access to production is a very different risk from an internal dashboard reading an API with potentially sensitive data.
The Operational Assessment
From there, a standardized assessment can fill in the more operational questions. This is also something the agent can do relatively easily in combination with the builder:
- Is a customer, another team, an agent, or another system depending on it?
- Does it introduce a new third-party service or processor?
- Are appropriate access controls and an audit trail in place?
- How are dependencies and known vulnerabilities tracked and updated?
- Is it monitored with appropriate alerting and instrumentation?
- If it fails, changes, or exposes data, could that create a contractual, privacy, security, or significant operational consequence?
These questions aren’t a complete compliance framework nor are they intended to be. They’re intentionally placed tripwires to ensure the right kinds of things get surfaced.
The output of that assessment also needs somewhere durable to live (like a Notion database). That gives you an inventory of what was built, who owns it, what it touches, and what classification it currently carries.
Most builders don’t need to know which ISO controls apply or how a SOC auditor will interpret the system. They need enough information to recognize, “This touches customer data and I’m not sure if I need to do anything with that information,” or, “Customers are depending on this and nobody has looked at how it’s maintained.”
That’s the moment Compliance, Security, or the relevant expert needs a path into the process. But how they enter is also important. The builder is watching what happens to the first thing that gets flagged. If the expert shows up to help close the gap and the builder keeps ownership, there is a much greater chance that the expertise will be sought out in the future.
The goal is to close the gap while keeping the person who found a useful way to solve a problem willing to keep building and sharing.
Recognition Needs Redundancy
In a perfect world, the first layer would be the builder recognizing that they’ve crossed a threshold. If they miss it, their manager is the next layer that would catch it. If they both miss it, Engineering, Security, and Compliance still need independent ways to notice.
Ultimately leadership owns designing the system so no single missed signal breaks the chain.
At Mapp, one of those sensors is a Notion agent I’ve written about before. It watches Slack channels where people already share what they’re building and looks for signals like customer data, production access, or new integrations. What matters is what it doesn’t do: it doesn’t decide whether something is compliant. It can ask follow-up questions and route what it finds to someone who can make that judgment.
That’s the defense-in-depth model. Each layer exists because the others can miss something.
The point isn’t surveillance. The point is that the compliance system can’t depend on every new builder independently rediscovering decades of engineering, compliance, privacy, and security practices. Especially not when much of the excitement around vibe-coding comes from something genuinely valuable: people who understand a problem can finally solve it themselves instead of translating it into a ticket and waiting for Technology to prioritize the work and turn their understanding into software.
That independence is worth preserving. It also changes where responsibility has to sit.
Building Distributes, Accountability Doesn’t
The defense-in-depth model above isn’t only about catching more things. It also reflects a split in responsibility between the people building the software and the leadership accountable for what gets built.
In the EU, NIS-2 and the Cyber Resilience Act make two different parts of that responsibility concrete: who is responsible for governing cyber risk, and what happens when distributed building creates a product with its own security obligations.
I want to be specific about those obligations because vague warnings about “compliance risk” mostly create FUD (Fear Uncertainty Doubt) and aren’t really actionable.
NIS-2: Governance Sits With Management
NIS-2 makes the governance issue around software development explicit. Article 20 requires the management bodies of in-scope organizations to approve cybersecurity risk-management measures, oversee their implementation, and allows them to be held liable for infringements.
In plain English: for an in-scope company, cybersecurity governance is a management responsibility. It isn’t something executive leadership can simply delegate to the CTO or Security team and consider it handled.
That doesn’t make the individual builder irrelevant either. In fact, it clarifies the split in responsibility I’ve already been describing. It also raises the practical question for distributed building: if management owns the governance, what does the person actually building the software own?
Builders need enough awareness to recognize and surface risk. Leadership owns the system that makes that possible.
The person vibe-coding a workflow doesn’t need to become a NIS-2 expert or work out which articles apply to them. In the operating model I’m describing, their responsibility is much simpler: they need enough awareness to recognize, “This touches something important; I should surface it.”
They’re not surfacing it so Compliance or Engineering can take over the software. They’re surfacing it because someone with the right context needs to determine whether an obligation or meaningful risk has been triggered and what, if anything, needs to change. Compliance might classify the risk themselves or bring in Security, Legal, Engineering, or whoever has the expertise the situation requires.
For management, that system means specifying the context, safe and sane defaults, tripwires, and people who respond when something crosses a threshold.
NIS-2‘s training requirements point in the same direction. Members of the management body — roughly, the senior leadership team or board-level group legally responsible for governing the organization — have to follow training. EU Member States are also supposed to encourage those organizations to offer similar training to employees so they gain enough knowledge and skills to identify risks and assess cybersecurity risk-management practices.
The useful takeaway here isn’t that everyone should learn NIS-2. It’s that people need enough knowledge to recognize when they’ve reached the edge of what they can safely decide themselves.
Their decisions create the technical reality that management has to govern.
And that accountability isn’t assigned to “whoever runs Engineering or IT.” It sits with the management body as a whole. If software creation spreads into Solutions, Sales, Marketing, Operations, or the executive team, decentralizing the building doesn’t decentralize the governance obligation. The EU Commission describes NIS-2’s management liability provisions as a way to ensure real accountability at the organizational level. How liability ultimately lands on individual executives depends on national law and the individual organization’s management structure.
CRA: When Distributed Building Becomes a Product
The Cyber Resilience Act adds a related pressure from the product side. It applies to covered hardware and software products made available on the EU market rather than being a general regulation of every internal application or SaaS workflow. But if distributed builders start shipping things such as plugins, SDKs, browser extensions, or mobile apps to customers, the company can become the “manufacturer” and take on security and vulnerability-management obligations across the product lifecycle.
The person who built the plugin doesn’t need to know the phrase “product with digital elements” to create something that gives the company CRA obligations. That’s the problem: the act of building can cross a regulatory threshold the builder didn’t know existed.
And this is precisely the kind of threshold the system above is supposed to catch. The builder doesn’t need to know the CRA cold nor ask their agent to assess the project every time. Someone needs to notice when what started as “I built a thing” has become software being shipped to customers.
That identification is important because some CRA obligations can arrive before the rest of the Act goes into full effect. The CRA’s reporting requirements for actively exploited vulnerabilities and severe incidents have applied since September 11, 2026 even though its main obligations don’t begin to apply until December 11, 2027. If you don’t recognize that you’ve crossed into CRA territory, you may not even know that those reporting obligations apply.
That doesn’t mean most internal tools suddenly fall under the CRA. They probably won’t. But once distributed building starts producing software that customers install, whether the builder thought of themselves as a (using the CRA terminology) “manufacturer,” is no longer the interesting question.
Different Obligations, Same Operating Problem
NIS-2, the CRA, GDPR, SOC-2, and customer contracts all create different kinds of obligations. There isn’t one blanket set of controls you can push down to every builder and call the problem solved.
That’s why the model above generalizes what can be generalized: safe and sane defaults, common controls, basic education, and clear signals for when the situation needs expert attention. The interpretation of the actual obligation can (and should) stay with the people who understand it.
That’s the balance I’m after: push enough context and education down that people can build responsibly without pushing the entire compliance burden down with it. Keep the more complicated judgment with the people who actually know how to make it.
The expertise can stay concentrated. The ability to recognize when you need it can’t.
But even a system designed that way is going to miss things.
So what happens when the first time Compliance sees something, is after customers are already using it?
Once You Find the Gap, Don’t Pretend You Can Go Back in Time
Sometimes that’s exactly what happens: your real compliance plan meets the organization this wonderful new world of vibe-coding has created for you.
You’ll discover a tool that’s been running for 4 months. 3 customers depend on it and it has prod access. Nobody has been tracking its dependencies. The person who built it has never heard of CVEs and doesn’t know library management or supply chain attacks are things they need to care about. That isn’t carelessness. It’s what happens when someone with deep expertise in the problem, but not in operating software, can suddenly build software themselves.
The cleanest policy answer may be to shut it down until it completes all the missing (security, compliance, etc) reviews. And sometimes, that is the right answer.
But if there isn’t an immediate security or privacy reason to stop it, taking a customer-dependent system offline while weeks of process catch up can create a different set of risks. You might break a live customer workflow, miss a contractual delivery or support commitment, or force people into a manual workaround that’s less controlled than the software you’re trying to remediate. Or simply just piss off a customer that was recently made happy by this new functionality.
Compliance and Engineering also have limited capacity. If surfacing an existing gap automatically triggers a shutdown and a multi-week review, people learn very quickly not to surface anything at all. Then you’re right back to the visibility (Shadow-IT) problem.
The better response is classification.
What is the actual risk right now? Which gaps need to be fixed immediately, and which can be remediated over time? Who owns the software and its ongoing maintenance? Do we need to limit further use until the highest-risk gaps are closed?
There will absolutely be cases where the right answer is “stop this now.” That’s why you assess the risk.
But “stop everything until certified” isn’t a compliance strategy for distributed building.
It is, however, an excellent strategy for backlog generation.
You also don’t want to throw away weeks or months of useful work from someone who understood the problem well enough to solve it. The goal is to bring what they’ve built into a documented process, fix the dangerous parts first while educating, and move it toward the level of rigor its actual use now requires.
Make the Safe Path the Easy Path
Classification and remediation deal with the software you’ve already found. The better long-term move is to reduce how often builders need remediation in the first place.
Recognition tells you when the defaults aren’t enough. The other piece (aka. the third part of exporting compliance) is making as many of those defaults as possible inheritable and easy to reuse.
Give builders an approved deployment path with authentication, secrets management, logging, dependency scanning, auditability, and basic observability already present. Give their agents supported templates and data-access patterns to start from, and load some of the relevant compliance context (typically via documentation) by default for their agent. Every control handled by the foundation is one less thing an individual builder has to understand or remember.
That doesn’t eliminate assessment. Someone can use an approved template and still connect it to the wrong data, expose it to the wrong people, or add a dependency that creates a new risk. The goal is to have the builder inherit as much of the compliance work as possible before they have to make a compliance judgment themselves.
The inventory should also tell you where the foundation is incomplete. If the same exception keeps appearing — the same customer integration, data flow, or internal tool — that’s a desire path. Turn that repeated pattern into another paved road so the next builder inherits more of the compliance work automatically. And where possible, retrofit the same controls into the tools that already exist.
Compliance Has to Follow the Lifecycle
Exporting compliance can’t stop with the first assessment. Hopefully that assessment happens before the thing reaches production. Even getting builders into the process once is hard enough; keeping the software inside that process as it changes is a separate problem.
A prototype gets its first customer. Then its third. Someone adds PII to make it more useful. A read-only integration gets write access. Another workflow starts depending on it. External input gets connected to an agent that can take action.
Software can cross a compliance boundary without crossing an organizational one. Nobody has to formally decide that “this is production software now” for its actual use to change what obligations apply to it.
The context, controls, and classification have to follow the software as its role changes. Otherwise yesterday’s correct assessment becomes today’s false sense of coverage.
This is the compliance version of Infrastructure by Adoption: reality can promote software before your process does.
That’s why the inventory needs to be durable rather than a one-time compliance artifact. Changes in capability, data, adoption, or dependency should trigger reassessment.
AI can and should do most of the mechanical work around those assessments. An agent can inspect the repository, identify dependencies and integrations, compare the current state with the previous assessment, and draft evidence of what changed over the course of development. It can also compare those changes with the builder’s intent captured in the conversation.
But this is one of the workflows I would deliberately keep at agent-propose, human-approve rather than treating full autonomy as the ultimate goal. The agent can identify the evidence and suggest the classification. Someone still needs to own the judgment about what happens next. That’s why you have compliance experts.
Automate the evidence gathering. Don’t automate away the accountability.
Keep the Building, Keep the Controls
The point of all of this isn’t to rebuild the old compliance process around a new class of software.
If Compliance wins by forcing every new thing back through the same gates, you lose much of what made distributed building valuable in the first place. People closest to problems lose the ability to solve them quickly, or they learn to build around the process instead of through it.
The opposite outcome is just as bad. If distributed building “wins” by treating everything outside Engineering as somehow exempt, the company keeps the speed but loses the controls, context, and accumulated experience that made the old model work.
Neither place is where you want to end up.
The goal is to let people keep building while making it difficult for what they build to outrun the company’s obligations. Compliance has to show up close enough to the work that builders can inherit what the company already knows, recognize when they’ve crossed a threshold, and get help without giving up ownership of the thing they built.
The job isn’t to drag all software back into the pipeline. It’s to make sure the controls can leave it.
