When Experiments Go Live

Enabling business teams to build their own applications creates new opportunities. They often have the deepest understanding of their processes, requirements and everyday challenges. Generative AI and vibe coding lower the technical barriers and make it possible to test ideas quickly.

The transition to production software, however, is rarely clear-cut. A personal productivity tool can quickly become something an entire team relies on. At that point, familiar software engineering questions arise: Who can access which data? Who is responsible for maintenance and updates? And who takes care of operations?

A professional-looking interface does not answer these questions. Security, data protection and maintainability remain essential – regardless of whether the code was written by developers or generated with the help of AI.

The role of AI itself also matters. An application developed with AI is not necessarily an AI system. If the application uses an AI model at runtime or sends company data to an external AI service, additional requirements around governance, data protection and potentially regulation come into play.

Enable Innovation with Clear Guardrails

The answer is hardly to prevent experimentation or subject every small productivity tool to an extensive approval process. Instead, companies need a pragmatic path from experimentation to regular operations.

This includes approved tools, clear rules for handling company data and criteria for determining when an application requires professional review. As an application becomes more important, clear ownership of security, maintenance and operations needs to be established as well.

Conclusion

Generative AI can turn valuable process knowledge into working solutions much faster. But it does not make professional software development obsolete. Instead, the role of software engineering is evolving: helping turn successful experiments into secure, maintainable applications that can be operated reliably over the long term.

When business teams and software engineers manage this transition together, a quick prototype can become a dependable tool.

Good Engineering Practices Pay Off

The new regulations require, among other things:

• CRA: Software Bills of Materials (SBOMs), vulnerability management and security updates.
• NIS2 and DORA: Incident reporting obligations and documented risk management.
• AI Act: Technical documentation, data quality measures and human oversight, depending on the risk category.

These requirements are no longer limited to large enterprises or regulated industries. Through supply chains and international business relationships, they increasingly affect software companies in Switzerland and beyond.

For organisations that already integrate quality, security and maintainability into their development processes, the new regulations are less about starting from scratch and more about demonstrating existing engineering excellence. Compliance is becoming a mark of quality rather than just another cost factor.

Companies that adopt Security by Design create many of the required artefacts during the development process itself. CI/CD pipelines, automated testing and Software Bills of Materials (SBOMs) make documentation a natural outcome of modern software engineering instead of an afterthought.

Learn more in our article “Thinking Security Strategically”.

Act Now Instead of Catching Up Later

DORA already applies, the main obligations of the CRA will take effect by the end of 2027, and the AI Act is being introduced in stages. Organisations that evolve their engineering practices today will not only be better prepared for compliance but also strengthen their long-term competitiveness.

AI has quickly become the default

In many projects, AI is now used by default — whether for writing code, generating documentation, or producing content. What starts as a productivity boost often turns into standard practice, without much reflection on its actual value.

That’s where the real challenge lies: not every task needs AI – and not every use of AI makes sense.

Sustainability starts with conscious decisions

Using AI has real implications — both technically and organizationally. Behind every AI-powered feature are resource-intensive infrastructures, rising costs, and increased system complexity.

At the same time, a familiar pattern is emerging: content is generated, refined, and condensed again — often without delivering real value.

Architecture over hype

Integrating AI into a system is always an architectural decision. Using large models typically introduces dependencies — on cloud providers, proprietary technologies, or specific platforms.

These dependencies affect not only how systems are built, but also how flexible they remain over time. Sustainable software development therefore means actively managing these trade-offs, rather than focusing only on short-term gains.

Conclusion

Artificial intelligence is a powerful tool but not an end in itself.

Sustainable software is built where technology is applied deliberately and decisions are made consciously. Sometimes, that also means choosing not to use AI where it doesn’t provide real value.

Security by Design: Embedding Security Where It Matters Most

Cybersecurity fails rarely because of missing tools, but because security is addressed too late. Security by Design ensures that risks are considered from the very beginning, forming the foundation for robust and trustworthy digital systems.

Organisations that postpone security decisions until shortly before go-live face unnecessary risks, higher costs and avoidable operational disruptions. Early, strategic integration of security prevents exactly that.

Why Security Must Start Early

Digital products and platforms are becoming increasingly complex, and weaknesses in the foundation are difficult or impossible to fix later. Security by Design means:

• identifying risks during planning
• building security directly into the architecture
• considering security as a first-class requirement

Studies consistently show that issues discovered late in the lifecycle are exponentially more expensive to fix than those addressed early. Treating security as an architectural concern reduces long-term costs and strengthens resilience.

Shift Left & DevSecOps: Practical Ways to Build Secure Software

Many modern organisations rely on Shift Left and DevSecOps to operationalise Security by Design. These approaches integrate security into processes and teams rather than treating it as a separate discipline.

Key practices include:

• automated security tests in CI/CD pipelines
• versioned, auditable policies (“Security as Code”)
• continuous monitoring and clear feedback loops
• shared responsibility across engineering, security and operations

The result: fewer vulnerabilities, more stable systems and faster release cycles.

Regulatory Requirements and Strategic Benefits

With the GDPR and the revised Swiss Data Protection Act, Security by Design is not merely best practice — it is a legal requirement. rganisations must implement appropriate technical and organisational measures from the design phase onward, including data minimisation, encryption and clear access controls.

Those who apply these principles consistently benefit twice: they meet regulatory expectations while strengthening the security and reliability of their digital landscape.

Conclusion

Security by Design is not an additional effort, but an investment in quality, resilience and trust. Organisations that consider security early develop faster, more reliably and more economically.