Key points on in-house software development
- Vibe coding makes software development accessible to all profiles, including non-technical users.
- Developing software internally (through a dedicated IT team or vibe coding) transfers responsibilities that were previously borne by external software providers.
- Without formalised traceability, data generated by internally developed software may be legally challenged.
- For software with regulatory significance, using a qualified Trust Service Provider is not optional.
The risks of in-house software development
Not all software carries the same level of sensitivity. Applications that process regulated data, generate documents with legal effect or form part of audited processes expose businesses to risks that an external software provider would otherwise assume.
Technical risks
Software developed without a structured methodology accumulates technical debt silently. The code may become unstable. However, the most underestimated risk lies elsewhere: without documentation of the code itself, nobody understands how it was built, which dependencies it relies upon or which technical decisions were made. Maintaining or evolving the software can therefore become difficult, if not impossible.
For example, a salesperson develops an order-tracking application through vibe coding. Eighteen months later, an operating system update creates an incompatibility. No one within the business has sufficient understanding of the code, or of how it was created, to intervene.
Cybersecurity risks
A SaaS provider maintains dedicated security monitoring and regularly releases patches. An internal IT team rarely has comparable resources. The risk is even greater when code has been generated by AI without any security review. According to Veracode’s GenAI Code Security Report, 45% of code-generation tasks assigned to large language models introduce a vulnerability listed within the OWASP Top 10, including SQL injection vulnerabilities, hard-coded passwords and exposed API keys.
The absence of governance over the code produced is the real risk: unverified code is unsecured code, regardless of its apparent quality.
Legal and evidential risks
Internally developed software may generate data whose reliability the business must be able to demonstrate before a court when dealing with sensitive matters subject to significant regulation. An internally developed electronic signature solution, a contract management module or a regulated document archiving system all fall within this category.
The same applies where a business deploys an internally developed HR time-tracking application. An employment dispute arises two years later. The opposing party does not need to prove that the data was altered. It is sufficient to demonstrate that the data could have been altered. In the absence of formalised traceability, the business cannot establish its integrity.
Compliance risks (GDPR and the AI Act)
Any internally developed software that processes personal data must comply with the GDPR from the outset. The principle of privacy by design requires data protection to be incorporated into the initial technical choices rather than added afterwards. A SaaS provider will generally have already embedded these requirements into its product. This is not automatically the case for internally developed tools, which may therefore be unable to provide any time-stamped evidence of user opt-ins during a regulatory inspection.
The AI Act introduces an additional constraint for AI systems integrated into internal processes. Certain tools developed through vibe coding, particularly those involved in HR or commercial decision-making, may fall within the category of high-risk systems. A business deploying such a tool without realising it may find itself without any compliance documentation when it is required.
Intellectual property risks
Ownership of internally developed code is not automatically acquired. Where software is created by an employee in the course of their duties, the economic rights generally vest in the employer, provided the conditions set out in Article L.113-9 of the French Intellectual Property Code are satisfied. Where code is generated by AI, the position remains unresolved: no legal rule expressly assigns ownership to the organisation that submitted the prompts.
AI-assisted development introduces an additional risk. Models may generate code resembling proprietary or copyleft-licensed libraries without the business being aware of it. For example, a company develops business software through vibe coding with the intention of commercialising it. It later discovers that the generated code incorporates excerpts licensed under the GPL. It must then either publish its entire source code or redesign the software.
Financial impact
The true cost of in-house development is often underestimated at the time the decision is made. Developer salaries, corrective maintenance, functional enhancements and bug fixes accumulate over time. In the case of vibe coding, token consumption costs also increase as the project becomes more complex and prolonged.
Governance and traceability: what in-house development requires
In response to these risks, three pillars should structure the organisation’s approach.
Traceability of AI-assisted development
Where code is generated by AI, an additional question arises beyond those associated with traditional software development: who prompted what, when, and against which version of the code?
Without traceability of AI prompts, it becomes impossible to distinguish between human decisions and AI-generated output. The consequences directly affect legal liability and ownership of the resulting code.
Timestamping and evidential value
A Git repository records modifications made to code. It does not certify the date of those modifications, the identity of their author or their integrity in the legal sense of the term. A commit can be backdated. An author identity can be falsified.
Qualified electronic timestamping under the eIDAS Regulation addresses this limitation. It anchors each stage of a project in time in a manner enforceable against third parties, benefiting from a presumption of accuracy that no internal tool can provide. For software with regulatory significance, this layer of trust cannot be improvised at the end of a project; it must be established throughout the development process.
Consider the case of a business facing litigation concerning a customer contract management system. It must demonstrate that a specific version of a contract was indeed the version in force on a given date and that it was not subsequently altered. Without qualified timestamping of software versions, it has no enforceable evidence with which to do so.
Using a qualified Trust Service Provider
For regulated software applications (such as electronic signature solutions or evidential archiving systems), choosing not to use a qualified Trust Service Provider has a direct consequence: in the event of litigation or a regulatory inspection, the burden of proof rests entirely with the business, without it having the necessary tools to discharge that burden.
Solutions such as Evidency enable this layer of trust to be integrated directly into the development workflow through APIs. The autonomy offered by in-house development is not compromised. However, the traceability and evidential value of the resulting software are significantly strengthened.
In-house software development increases the need for trusted third parties
In-house software development addresses genuine business needs. It offers autonomy, responsiveness and control over the software produced. However, the more software a business develops internally, the greater its need to rely on qualified trusted third parties for software that carries legal consequences.
For applications that process regulated data, generate legal documents or form part of auditable processes, enforceable traceability and the use of a qualified Trust Service Provider are not additional precautions. They are indispensable safeguards that allow organisations to preserve their software autonomy without weakening their legal position.
Disclaimer
The opinions, presentations, figures and estimates set forth on the website including in the blog are for informational purposes only and should not be construed as legal advice. For legal advice you should contact a legal professional in your jurisdiction.
The use of any content on this website, including in this blog, for any commercial purposes, including resale, is prohibited, unless permission is first obtained from Evidency. Request for permission should state the purpose and the extent of the reproduction. For non-commercial purposes, all material in this publication may be freely quoted or reprinted, but acknowledgement is required, together with a link to this website.
