The Draupnir Effect: Vibe Coding, Shadow GRC, and the Hard Reality of Building Enterprise Software
In Norse mythology, Odin possessed a golden ring called Draupnir. Every ninth night, Draupnir produced eight new rings of equal weight. It represented abundance, power, and the almost supernatural multiplication of something valuable.
Someone appears to have dropped Draupnir into the modern software market.
Every day, another platform appears in my inbox . . .
- A new risk application.
- A new compliance tool.
- A new AI governance solution.
- A new third-party risk platform.
- A new control-testing engine.
- A new supplier/third-party risk application.
- A new enterprise GRC platform.
Increasingly, these are presented not as focused applications, but as entirely new GRC platforms poised to disrupt an established market because they have a modern interface, a conversational assistant, and none of the obvious baggage of legacy technology.
One ring becomes eight. Eight become sixty-four. By the end of the month, the marketplace is covered in golden circles, each polished for a demonstration and each claiming to be the original artifact.
This is not simply a GRC issue . . . Vibe coding is changing software development across every industry. It allows people to move from an idea to a functioning application at extraordinary speed. A consultant can turn a methodology into software . . . A risk professional can build a workflow without waiting for the technology department . . . A compliance team can replace a spreadsheet . . .A founder can create a prototype without first raising millions of dollars or assembling a large engineering organization . . .
That democratization is real, and I welcome it. Some of the most interesting innovations in software will come from subject-matter experts who can finally express their ideas directly in technology.
But democratized creation also produces democratized delusion.
The ability to create a working application does not mean someone has built a viable product. A viable product is not automatically an enterprise platform, nor is it automatically a sustainable company, and a sustainable company is not automatically capable of competing in a complex, crowded, and demanding market such as GRC.
Vibe coding has dramatically shortened the distance between an idea and a demonstration. It has not eliminated the much greater distance between a demonstration and dependable enterprise software.
The Marketplace of Golden Rings
The current software market is being flooded with applications that look impressive at first glance. A polished interface asks a user a few questions, generates a risk statement, assigns a score, recommends a control, summarizes a regulation, and creates a dashboard. A chatbot then drafts a policy, classifies an incident, or recommends remediation. The demonstration is smooth, modern, and often more attractive than the interfaces of platforms that have been in the market for fifteen or twenty years.
Then comes the declaration that the established GRC market has been disrupted!!!
I understand the temptation. Many established platforms are slow, expensive, difficult to configure, and frustrating to use. Some carry years of technical debt. Others have grown through acquisition and now consist of multiple products, interfaces, data models, and code bases joined together with varying degrees of elegance. Their licensing structures sometimes appear to have been designed by Loki after a particularly mischievous evening (particularly Service Now’s).
There is room for disruption. There is a need for it.
But disruption requires more than a prettier screen and an artificial intelligence model that has partially learned the language of risk and compliance.
A consultant may understand a regulatory framework exceptionally well and create an elegant application around it. That risk professional may design a better assessment workflow than anything found in a traditional platform. Or that bank, insurer, hospital, or technology company may build an internal application that perfectly suits one part of its operating model. These can all be valuable achievements.
They do not automatically constitute an enterprise GRC platform that can be sold, implemented, secured, maintained, supported, and evolved across hundreds of organizations.
This is where the current enthusiasm becomes dangerous. The ease of creating the first visible portion of an application gives teams the impression that most of the work is complete. In reality, the demonstration is often the easiest part. Beneath that demonstration sit several much harder disciplines:
- Architecture must preserve coherence as complexity grows. The application has to support relationships, hierarchies, histories, permissions, workflows, integrations, and changing organizational structures without becoming brittle every time a customer adds another business unit, framework, jurisdiction, or use case.
- Security and governance must be designed into the product rather than added when the first large prospect asks difficult questions. Identity, access, segregation of duties, encryption, auditability, retention, privacy, model governance, and explainability are not optional enterprise features. They are conditions of entry.
- The product must be repeatable. A platform that works only when the founders configure every workflow, repair every integration, and personally explain every design decision is not yet an enterprise product. It is a collection of bespoke projects held together by heroic effort.
- The provider must be able to deliver what it sells. Implementation methodology, migration tools, documentation, testing, upgrades, support, training, customer success, and operational resilience are part of the solution, even though they rarely appear in the opening demonstration.
The front end may shimmer like gold. That tells me very little about what lies beneath it.
GRC Is Not a Collection of Forms
One of my greatest frustrations is the persistent belief that GRC is essentially a collection of digital forms, questionnaires, registers, attestations, and dashboards. This misconception existed long before vibe coding, but vibe coding now makes it easier to perpetuate.
A developer creates a risk form, a control form, and an issue form. The records can be linked. A dashboard shows red, amber, and green (BARF). Perhaps an AI assistant generates descriptions and recommends scores. Suddenly, the application is described as an enterprise GRC platform.
But GRC is not a set of isolated records. It is a complex and dynamic system of relationships.
An objective may depend on several business processes. Those processes rely on people, technology, facilities, information, suppliers, and services. Each dependency introduces uncertainty. Risks may affect multiple objectives, entities, products, or jurisdictions. Controls may address several risks and obligations but operate differently across business units. A regulatory requirement may connect to policies, procedures, controls, evidence, tests, issues, and accountable individuals. An incident may reveal a control failure, trigger a legal obligation, expose a supplier dependency, disrupt a critical service, and threaten a strategic objective.
This is a many-to-many world. Everything connects to something else, and every connection carries context.
That context includes ownership, authorization, history, versioning, geography, legal entity, business hierarchy, data sensitivity, applicability, evidence, accountability, and time . . .
- It matters who approved a control, which version was effective, what evidence supported it, which business units relied upon it, and what changed after an incident.
- It matters whether a user can view a record but not edit it, whether responsibility can be delegated, whether approval requires segregation of duties, and whether the entire history can be reconstructed for a regulator, auditor, board, court, or internal investigation.
A simple application can create a relationship between two records. An enterprise GRC platform must manage thousands or millions of relationships consistently, securely, and historically across the organization.
That is architecture, not decoration.
Without that architecture, organizations gradually accumulate disconnected applications . . .
- The risk tool does not communicate with incident management.
- The compliance application maintains its own control library.
- The third-party risk solution uses a different supplier record than procurement. Policy management has its own workflow and identity structure.
- Audit tracks findings somewhere else.
- Operational resilience has another view of critical processes and dependencies.
The same employee may exist in five applications. The same control may be duplicated eight times. The same supplier may have three names and four risk ratings. The same obligation may be interpreted differently by compliance, legal, information security, and internal audit.
Eventually, the organization exports everything into spreadsheets to reconcile reality . . . That is not GRC transformation. It is fragmentation with a modern user interface.
When Every Department Becomes Its Own Software Company
The external flood of new software companies is only half of the Draupnir effect. The same multiplication is now happening inside organizations.
For years, GRC teams have waited for overloaded technology departments and slow enterprise platforms to address relatively simple needs. They submit enhancement requests, enter project backlogs, compete for development resources, and wait months for changes that appear straightforward. When someone can now describe the application they want and generate a functioning version in days, the temptation to bypass those constraints is entirely understandable.
In many cases, internal experimentation is healthy. A team may use vibe coding to test an idea, replace a spreadsheet, automate a narrow process, or prove that a better workflow is possible. The problem begins when experimentation quietly becomes production, and production quietly becomes critical infrastructure . . .
- Compliance creates an application for regulatory assessments.
- Information security builds another for control testing.
- Operational risk develops an RCSA tool.
- Internal audit generates an evidence-management application.
- Procurement creates a supplier-risk workflow.
- Business continuity builds another application for impact analysis and recovery plans.
Each application solves a real problem. Each team is proud of what it has created. Each application may work exceptionally well within its original boundary . . . Collectively, they can become a governance nightmare.
The resulting problems are not theoretical:
- Definitions fragment. Risk, control, issue, incident, asset, supplier, process, and business service begin to mean different things in different applications. The organization gains several technically correct but operationally incompatible versions of reality.
- Identity and accountability fragment. The same person receives different roles, permissions, and responsibilities across separate tools. A control owner in one application may not be recognized as the same owner in another, while approvals and delegations become impossible to reconcile.
- Data fragments. A critical supplier in one system may not match the supplier record used by procurement. A control tested by information security may be duplicated in compliance and duplicated again in internal audit. An incident may remain isolated from the obligations, policies, risks, and objectives it affects.
- Governance fragments. Each team creates its own retention rules, security decisions, model prompts, workflows, evidence standards, and approval structures. Local flexibility grows while enterprise assurance quietly erodes.
The organization has not democratized GRC. It has democratized fragmentation.
There are also serious questions of ownership and sustainability . . .
- Who supports the application when its creator leaves?
- Who validates the security model?
- Who tests changes?
- Who monitors integrations?
- Who ensures the AI continues behaving appropriately?
- Who manages privacy, retention, records requirements, accessibility, resilience, and recovery?
- Who is accountable when the application produces a flawed recommendation or quietly stops working?
The irony is difficult to miss. An organization may create an internally vibe-coded third-party risk application while failing to apply equivalent due diligence to the libraries, models, cloud platforms, connectors, and development services on which that application depends.
Internal development does not eliminate third-party risk. It often hides it.
The answer is not to prohibit internal innovation. A blanket prohibition would drive experimentation underground and preserve many of the inefficiencies that created the demand for these tools in the first place. The answer is governed enablement.
Organizations need an architecture and operating model that allow teams to innovate without creating uncontrolled islands. This requires more than publishing a policy that says “use AI responsibly.” It requires practical infrastructure and decision rights:
- Teams need approved environments and reusable foundations. Common identity services, security controls, enterprise records, integration patterns, data models, and monitoring services allow local innovation without requiring every team to rebuild the foundations of enterprise technology.
- Every application needs an accountable owner and defined lifecycle. The organization should know what is being built, what data it uses, which decisions it influences, who supports it, how changes are tested, and what happens when it fails or is no longer needed.
- There must be a path from experimentation to industrialization. A prototype may remain a local tool, be rebuilt on an enterprise platform, become part of a broader GRC architecture, or be retired after proving the concept. What it should not do is drift silently into becoming a critical control environment.
- AI behavior must be governed as part of the application, not treated as an invisible service. The organization needs to understand which models are used, what data is shared, how prompts and agents are controlled, which actions require human approval, and how recommendations can be traced and challenged.
Without these guardrails, every department becomes its own software company without possessing the architecture, engineering, governance, funding, or support capabilities of an actual software company.
That is not agility. It is shadow IT with an AI accelerator.
Intelligence Requires Context, Not Merely Conversation
The arrival of generative AI has introduced another layer of confusion. The market increasingly equates conversational interaction with intelligence, as though the ability to ask a question in natural language proves that the system understands the organization.
A language model can produce an excellent risk statement. It can summarize a regulation, draft a policy, classify an incident, or recommend controls. These capabilities are useful and will become normal elements of GRC technology. But polished language is not the same as organizational intelligence.
Real GRC intelligence requires context. It must understand what the organization is trying to achieve, what processes and services support those objectives, which assets and suppliers those processes and services depend upon, what controls are expected to operate, what evidence exists, what incidents have occurred, and what uncertainty threatens performance.
Suppose an access-control failure is detected. A generic AI assistant may explain the weakness and propose remediation. A contextually intelligent GRC system should understand that the failed control applies to a specific application, that the application supports a critical payment process, that the process serves customers in several jurisdictions, that the application relies upon a particular cloud provider, that the provider has experienced recent incidents, and that the combined exposure threatens an important business objective and may create regulatory reporting obligations.
That intelligence does not arise because the system can chat. It arises because the system understands relationships, dependencies/interdependencies, history, permissions, and organizational context. It needs access to authoritative data, but access alone is not enough. The data must be governed, structured, connected, and understood within the operating model of the organization.
This is why I become cautious when a provider tells me that it has connected a general-purpose language model to several forms and created an intelligent GRC platform. The model may be intelligent in a broad linguistic sense, but the application may remain organizationally ignorant. It can speak convincingly about controls without understanding whether the controls exist, operate, apply, or have failed.
A chatbot may provide an answer. A GRC platform must support a defensible decision.
The Forge Matters More Than the Spark
The Norse gods possessed extraordinary artifacts, but those artifacts did not emerge from casual experimentation. Draupnir, Mjölnir, and Skíðblaðnir were forged by craftsmen with deep skill. Their value was not simply that they looked impressive; their value came from what they could reliably do.
Vibe coding provides the spark. It can help create prototypes, accelerate configuration, automate repetitive development, and bring new ideas to life. But the spark is not the forge, and it is certainly not the finished artifact.
The forge is the accumulated discipline required to build technology that survives the enterprise. It includes an architecture capable of handling complex relationships without collapsing under scale. It includes security models that enforce access across business units, legal entities, geographies, and sensitive data. It includes audit trails that preserve who did what, when, why, and under whose authority. It includes reliable performance, backup, recovery, release management, testing, and upgrade paths.
It also includes the institutional knowledge that comes from implementing software in real organizations. Experienced providers learn where implementations fail, where users resist, which configurations become unmanageable, and which apparently harmless customizations create years of technical debt. They learn that every customer believes its processes are unique, while many of the underlying problems are remarkably consistent. They learn when to adapt the technology and when to tell the customer that a requested design is a bad idea.
This knowledge is rarely visible in a demonstration, but it determines whether the system succeeds after the sales team leaves. A new provider may have brilliant engineers and a compelling idea. It may still lack the scars that produce sound enterprise judgment.
The Last Twenty Percent Is Another Continent
Vibe-coded development creates a psychological trap. Because the initial application appears quickly, founders and internal teams begin to believe the product is almost finished. The dashboard works . . . The workflow runs . . . The model generates output . . .The application can be shown to a prospect or executive sponsor . . .
Then reality arrives.
The enterprise customer wants single sign-on, granular permissions, configurable hierarchies, bulk data loading, APIs, data residency, encryption, audit logging, multilingual support, accessibility, role delegation, configurable notifications, retention schedules, workflow escalation, mobile access, and integration with a collection of systems that were last meaningfully documented during the reign of a previous CIO.
The customer wants the solution to support not one framework but twenty. It wants one control to map to multiple requirements. It wants inherited controls, shared services, regional variations, historical reporting, and evidence that can be reused without being blindly duplicated. It wants to understand what changed between last quarter and this quarter. It wants the platform to support twenty thousand users even though only two hundred may log in regularly. It wants the implementation completed in three months without disrupting the business.
Suddenly, the weekend prototype is standing at the edge of a very large ocean . . . or abyss!
This is where many promising solutions stall. The team built the visible application but not the administrative tooling, migration utilities, implementation accelerators, security architecture, monitoring capabilities, or support processes required to make the application repeatable across customers.
The remaining work is not another twenty percent. It is another continent.
Building Technology Is Not Building a Company
The deeper concern is that many new entrants underestimate not only the work required to finish the product, but also what it takes to bring the product to market.
The GRC market contains many strong technologies that have never achieved meaningful scale. Some have better architectures than larger competitors. Some offer more innovative approaches, stronger analytics, better usability, or more compelling ideas. Yet they remain relatively unknown, struggle to win enterprise deals, or eventually disappear.
Great technology is only one component of a successful technology company. Remember VHS vs BetaMAX from the 1980’s (well I do, showing my age) . . .
A provider entering this market has to execute across several interdependent disciplines:
- Positioning determines whether the market understands why the company exists. The provider must define the problem it solves, the buyer it serves, the outcomes it creates, and the reasons it is meaningfully different from dozens or hundreds of alternatives. Technical originality means little when the market cannot understand the value.
- Marketing creates sustained visibility and credibility. This is not a few enthusiastic posts announcing that legacy GRC is dead. It requires market education, thought leadership, customer evidence, events, analyst engagement, competitive intelligence, and a narrative that reaches beyond the founder’s immediate relationships.
- Sales converts interest into durable commercial relationships. Enterprise GRC purchases involve risk, compliance, audit, legal, information security, procurement, technology, privacy, finance, and executive stakeholders. The sales cycle may include workshops, demonstrations, proofs of concept, security assessments, references, contracting, and procurement processes extending for a year or longer.
- Delivery converts promises into outcomes. A provider needs repeatable implementation methods, trained consultants, migration capabilities, documentation, governance models, integration expertise, and the judgment to prevent every customer request from becoming permanent custom code.
- Support and customer success determine whether the customer stays. The platform must be maintained, upgraded, monitored, explained, and improved. Customers need someone accountable when the implementation becomes difficult, the model behaves unexpectedly, or a critical workflow fails.
- Capital and operational discipline allow the company to survive the gap between ambition and scale. Product development, long sales cycles, implementation capacity, market awareness, and customer support all consume resources before they create sustainable returns.
A company may close a significant enterprise customer and discover it has no repeatable implementation methodology, insufficient consultants, limited documentation, weak training materials, and no reliable way to migrate data. The founders become the implementation team, product support, solution architects, and escalation path. Every customer receives a different configuration. Every implementation creates new custom code. The product roadmap becomes hostage to the loudest account.
That is how an innovative platform becomes an unsustainable services project.
Sales, marketing, implementation, support, customer success, partnerships, and capital are not secondary functions to be added after the technology succeeds. They are part of the product’s ability to succeed.
Technology earns the right to enter the market. Execution determines whether it remains there.
The Demo-to-Delivery Chasm
I have seen many excellent demonstrations. Demonstrations are controlled environments. The data is clean, the workflow is logical, the user has exactly the right permissions, and nothing unexpected occurs. The AI correctly interprets the question. The dashboard loads. The process reaches its conclusion in ninety seconds.
Real organizations do not behave like demonstrations.
They have inconsistent taxonomies, duplicate records, unclear ownership, political disputes, fragmented systems, unfinished inventories, conflicting policies, regional exceptions, legacy processes, and users who enter data differently despite receiving the same instructions. One business unit believes the risk belongs to technology. Technology believes it belongs to operations. Operations believes compliance owns it. Compliance believes the business accepted it three years ago, although no one can locate the approval.
This is where a platform and its provider prove their value. The technology must be flexible enough to support reality but disciplined enough not to reproduce every organizational dysfunction inside the system. The implementation team must understand how to rationalize data, simplify workflows, establish governance, and guide the customer toward a sustainable operating model.
No amount of generative AI eliminates this work. In some cases, AI may accelerate the wrong design.
The ability to generate applications quickly can result in every department building its own version of risk, compliance, incidents, controls, and policies. Each application may be well designed in isolation, but together they recreate the silos that GRC was supposed to address.
Speed without architecture can industrialize fragmentation.
The Market Does Not Need Another Digital Risk Register
I am not interested in another application that takes a traditional risk register, places it in a browser, adds a chatbot, and describes the result as the future of GRC.
The market already has enough electronic filing cabinets, digital questionnaires, compliance checklists, and red-amber-green dashboards. Organizations do not need faster ways to document disconnected activity. They need technology that helps them reliably achieve objectives, address uncertainty, and act with integrity.
That requires systems that connect governance, risk management, and compliance to the actual business. It requires understanding how objectives depend upon operations, technology, people, suppliers, information, and decisions. It requires intelligence capable of identifying patterns, dependencies, and emerging exposure. It requires action that moves work forward and configuration that allows the organization to adapt without destroying coherence.
This is where AI, agents, orchestration, and conversational development become genuinely transformative. They can make GRC technology easier to use, more responsive, more proactive, and more aligned with decisions. But they must operate across a strong System of Record that preserves trusted data, relationships, accountability, and evidence.
The System of Record is not the obsolete past from which AI liberates us. It is the foundation that prevents AI-enabled GRC from becoming confident chaos.
Buyers Need to Look Beneath the Interface
Buyers need to become much more rigorous in evaluating new solutions. A modern demonstration and a compelling founder are not enough. They need to examine the technology, but they also need to examine the company expected to stand behind it.
At a minimum, buyers should press deeply into four areas:
- The architecture: How does the platform model relationships, histories, entities, permissions, inherited controls, shared services, and large volumes of records? Can it grow beyond the narrow use case shown in the demonstration without creating another silo?
- The governance: How are identity, security, auditability, retention, privacy, AI actions, model behavior, and configuration changes controlled? Can the provider explain what the system did, why it did it, what data it used, and who authorized the action?
- The delivery model: Does the provider have an implementation methodology, trained resources, migration tools, documentation, partners, and references? What happens when the customer’s data is inconsistent, its ownership is disputed, and its processes are nothing like the demonstration?
- The viability of the provider: Does the company have the leadership, funding, market strategy, support structure, and operational maturity to remain accountable throughout a multi-year relationship? Is the capability generally available, in beta, or still living entirely in a presentation?
Innovation deserves consideration. It does not deserve immunity from due diligence.
Builders Need to Decide What They Are Actually Building
Builders also need to confront reality . . .Building software has become easier. Building a durable software company has not.
A team entering the GRC market should decide what it is truly creating. It may be an internal application, a focused point solution, a technology-enabled service, a commercial product, or an enterprise platform. Each can be valuable, but each requires a different operating model, investment level, and market strategy.
Not every useful application should become a standalone software company. A consulting firm may create technology that strengthens its services without attempting to compete with global platforms. An internal compliance team may build an excellent application for its own environment without assuming that the same configuration will work elsewhere. A founder may choose to dominate a narrow problem rather than claiming to solve all of GRC.
There is discipline in focus.
A provider that genuinely intends to become a GRC software company must plan for years of investment. It must build product depth while also building sales, marketing, implementation, support, customer success, partnerships, and operational resilience. It must develop references, survive long buying cycles, and prove that its platform can move beyond a controlled demonstration.
The market does not reward technology simply because it is clever. It rewards providers that can turn technology into sustained customer outcomes.
Vibe Coding Is an Accelerator, Not an Exemption
I am not opposed to vibe coding. I expect it to become a normal part of software development and configuration. It will allow experienced providers to innovate faster, enable customers to shape applications around their needs, and bring valuable ideas into the market that might otherwise remain trapped in spreadsheets or presentation decks.
But vibe coding does not exempt anyone from architecture, governance, security, expertise, or execution.
It accelerates whatever already exists. In the hands of a disciplined team with deep domain knowledge and sound architecture, it can accelerate meaningful innovation. In the hands of a team that does not understand the problem, it can accelerate the production of fragile applications and technical debt.
It can scale good judgment . . . It can also scale bad judgment
The critical question is not whether a solution was vibe coded. The critical question is whether the people behind it understand what they are building, why it matters, how it fits into the broader enterprise, and what it will take to deliver and support it over time.
Forging Something Worthy of the Market
Draupnir produced endless rings, but mythology remembers the original because the original carried meaning, history, and power. Multiplication alone did not create significance. The same will be true in software.
The market will continue producing new applications at an extraordinary rate. Many will look polished. Some will solve meaningful problems. A few will mature into strong products. Fewer will become sustainable companies, and fewer still will establish the credibility, architecture, and execution required to become enduring enterprise platforms.
That is not cynicism. It is the reality of building technology that organizations can trust with governance, risk management, compliance, resilience, accountability, and decisions.
I welcome disruption. I want better GRC technology. I want platforms that are more intelligent, contextual, conversational, adaptive, and capable of orchestrating action. I want new providers to challenge legacy assumptions and force the market forward. I also want organizations to innovate internally and solve problems that established technology has neglected.
But I want buyers, builders, and internal teams to stop confusing speed with maturity, a demonstration with a product, a product with a platform, and a platform with a viable company.
Use AI. Experiment aggressively. Challenge the established market. Build applications through conversation. Create experiences that are dramatically better than what came before. Just remember that a spark is not a forge, a ring is not Draupnir, and a weekend prototype is not an enterprise platform.
The technology may be created quickly . . .Trust still has to be earned!