There is a growing narrative that AI is becoming a new kind of developer — a silent teammate who writes code on command, accelerates delivery, and fills skill gaps. But here is the distinction worth sitting with: AI is not writing code. It is emulating code. It predicts patterns based on what it has been trained on, blending fragments of the world’s repositories into outputs that often look convincing, sometimes useful, and occasionally problematic.
That distinction is more than academic. When a model generates code from patterns it has absorbed, it may also reproduce the vulnerabilities, outdated practices, or weak cryptography embedded within those patterns. But beyond security, another issue we cannot ignore is authorship. AI-generated code blurs the boundaries of ownership, licensing, accountability, and intellectual property in ways that most organisations are not yet prepared for.
The issue is not that AI makes mistakes; humans do that too. The issue is that AI blurs the boundaries of origin. A model cannot tell you whether the pattern it reproduced originally came from MIT-licensed code, GPL code, proprietary enterprise code, or a personal side project on someone’s laptop. It cannot explain intent. It cannot distinguish between an outdated cryptographic routine and a modern one. And it cannot describe the obligations that may travel with its output.
This is where responsible use becomes essential. If AI assistance is becoming a core part of how we build software, then organisations need visibility into how that assistance is shaping the code that enters their supply chain. Innovation does not slow down when transparency increases — it simply becomes safer to rely on at scale.
This is why I believe we are approaching a new layer of governance: an AI bill of materials. Not to control AI or constrain it, but to give organisations a way to understand how AI contributed to their systems. Just as SBOMs helped us catalogue human-produced components, an AIBOM could help track which models were used, what training sources shaped them, and what risks — legal, operational, or cryptographic — might result from their outputs.
The point is not to mistrust AI. The point is to avoid blind trust. AI is powerful in the way any tool is powerful: it magnifies both strengths and assumptions. When we understand how it works and what it draws from, we can use it with confidence.
The companies that succeed in the next decade will be those that combine AI-driven acceleration with governance that respects licensing, provenance, contributor identity, and cryptographic integrity. Tools such as SCANOSS AI Finder are early evidence that this layer is buildable — the harder work is organisational.
AI will continue to transform how software is created. But as leaders, our responsibility is to pair that transformation with clarity rather than with assumption.
If AI ever contributes to the next security breach, it will not be because AI is unsafe. It will be because we used it without the governance that keeps complex systems trustworthy.
It is time to build that future openly.
