The vendor delivered the quoting module two weeks early. At the wrap-up meeting, someone on your team casually asks how much of that code was written by an AI. Nobody really knows. Nobody knows either whether any of the 40 new dependencies carries a license that would force you to publish your code, or who owns the system if you switch vendors tomorrow.
Software development with artificial intelligence is now standard practice on almost every team, and that's fine: the repetitive work moves faster. The trouble is that AI-generated code carries risks that never show up in the demo. It can ship known vulnerabilities, dependencies nobody consciously chose, snippets that look a lot like licensed code, and open questions about intellectual property. If you want the big picture of what AI does inside a development team, we covered it in Software development with artificial intelligence today. This article is about what you should keep under control once that code lands in a system you own.
It compiles, which says nothing about security
In March 2026 Veracode published an update to its study on the security of AI-generated code. They have evaluated more than 150 models on the same 80 coding tasks, and the results have barely moved in two years:
- More than 95% of the generated code is syntactically correct.
- Only about 55% passes the security checks. In the remaining 45%, the model introduced a known vulnerability when nobody explicitly asked it to care about security.
- Results vary a lot by language. Python sits around 62%, Java at just 29%.
- Models handle SQL injection well but fail most cross-site scripting cases (15% pass rate) and log injection cases (13%).
That matches what we see on projects: AI writes code that works on the first try, and nobody questions it because it works. Security review can't depend on the model "remembering" to validate input.
Dependencies that don't exist (yet)
There's a less familiar risk too. Sometimes the assistant suggests installing a library that doesn't exist. A paper presented at USENIX Security 2025 analyzed 576,000 code samples in Python and JavaScript. On average, commercial models made up at least 5.2% of the packages they recommended, and open-source models 21.7%. In total, 205,474 distinct invented package names showed up.
The problem starts when an attacker registers one of those invented names on npm or PyPI with malicious code inside. The technique is known as slopsquatting. If a developer copies the install command without looking, the malicious package gets into the project.
The defense is boring, and it works. Every new dependency gets reviewed before it goes in: how long it has existed, who maintains it, how many downloads it has, and what license it carries. The project should also keep a lock file (package-lock, poetry.lock or equivalent) committed to the repository.
Open source licenses: the snippet that looks too familiar
A model trained on public code can return a block nearly identical to one sitting in a GPL-licensed repository. If that block ends up in your system, you could inherit license obligations nobody reviewed.
Enterprise tools already have controls for this. GitHub Copilot, for example, has a policy called "Suggestions matching public code" that an organization can set to block or allow those suggestions, plus a code referencing feature that shows which repository the matching code comes from and which license applies. One detail matters here: according to GitHub's February 2026 announcement, the Copilot coding agent doesn't honor the block setting. Matches get flagged in the session log, but they aren't blocked. If your vendor works with agents, someone has to read those logs.
Another question worth asking: is the team on enterprise plans with these policies turned on, or on personal accounts? With personal accounts, the company controls none of the above.
Who owns the code the AI wrote?
There are more gray areas here than we'd like, so it helps to separate what's settled from what isn't.
What's settled in Chile: Law 17,336 on intellectual property protects computer programs. Article 8 says that when a program is produced on commission for a third party, the rights are deemed assigned to that party "unless otherwise stipulated in writing." In other words, the contract rules. If the contract says something else, the code may not be yours even though you paid for it.
What isn't settled: Chilean law says nothing specific about AI-generated works. For reference, the U.S. Copyright Office concluded in its January 2025 report that AI-generated content is protected only where a human determined sufficient expressive elements, and that writing a prompt isn't enough. Using AI as an aid inside a larger human work doesn't bar protection. That's the U.S. position, not Chilean law, but it shows where the debate is heading.
With that in mind, these are the points we'd check in a custom development contract (this isn't legal advice; have your lawyer handle the final wording):
| Clause | What it should say |
|---|---|
| Ownership | Source code, documentation and tests belong to the client, including anything written with AI assistance |
| AI use | Which tools the vendor uses, with what kind of account and under what data terms |
| Third-party licenses | An inventory of dependencies and their licenses as part of the deliverable |
| Review | All code, generated or not, goes through human review before it's merged |
| Confidentiality | No personal data, credentials or sensitive code pasted into tools without an enterprise agreement |
| Handover | The full repository, with history, in the client's name when the project closes |
How to keep it under control day to day
None of these practices are new. What changed is volume: when AI writes more code per day, manual review alone can't keep up, and the checks need to be automated.
- Human review on every pull request, with a named owner. The pull request should state whether generated code is involved.
- Static application security testing (SAST) running in the CI/CD pipeline, not just before release.
- Software composition analysis (SCA) to catch dependencies with vulnerabilities or problematic licenses.
- Secret scanning, because an assistant can leave an API key pasted in the code without anyone noticing.
- Automated tests for business rules. We covered them in Automated software testing with AI: what actually works.
- A written AI usage policy for the team: which tools, which accounts, and what information never goes into a prompt.
If your vendor has all of this wired into the pipeline, the question of how much code the AI wrote matters a lot less. What you care about is that every line went through the same checks, wherever it came from.
Frequently asked questions
Is AI-generated code less secure than code written by people?
Not necessarily, but it does repeat known flaws often. According to Veracode, about 45% of samples generated without security instructions contained a vulnerability. Human review and automated analysis in the pipeline are what make the difference.
Can I forbid my vendor from using AI?
You can, but you'd lose some of the speed it delivers today. Demanding transparency usually works better: which tools they use, with which accounts, and that all code goes through the same review and security checks.
If AI wrote part of the code, is it still mine?
In Chile, commissioned software is deemed assigned to the client unless the contract says otherwise. Since the law doesn't specifically address AI-generated output, your contract should state explicitly that all the code is yours.
AI-assisted development, with controls from the first commit
At Disrupsoft we build custom web and mobile applications, with GitHub and CI/CD as part of everyday work. If you're evaluating a project and want to settle from day one how the code will be controlled, let's talk about your custom development.
