{"id":14483,"date":"2026-04-27T15:33:59","date_gmt":"2026-04-27T13:33:59","guid":{"rendered":"https:\/\/www.bayootec.com\/?p=14483"},"modified":"2026-05-28T12:54:06","modified_gmt":"2026-05-28T10:54:06","slug":"ai-in-everyday-developer-life-how-we-combine-cybersecurity-and-responsibility","status":"publish","type":"post","link":"https:\/\/www.bayootec.com\/en\/blog-en\/ai-in-everyday-developer-life-how-we-combine-cybersecurity-and-responsibility\/","title":{"rendered":"AI in everyday developer life: how we combine cybersecurity and responsibility"},"content":{"rendered":"

Productivity boost with side effects<\/h2><\/div>

There’s no doubt about it: AI support in development works. Microsoft researchers were able to show that teams with GitHub Copilot completed the same task around 50 percent faster than comparison groups without AI support. This order of magnitude is impressive and explains why AI tools have so quickly become commonplace in development teams around the world. <\/p>\n

But the same development has a downside that is slowly becoming apparent. A recent study by the security company Apiiro shows that developers who use AI assistants write three to four times more code, but also introduce ten times the amount of risks. These include unchecked open source dependencies, hidden backdoors in the generated code and inadvertently published access data. According to industry estimates, AI will have produced around 40 percent of the code written worldwide by 2025. So-called “vibe coding”, i.e. the intuitive generation of code through AI prompts without a deep understanding of the result, is a reality. <\/p>\n

Awareness of this is growing: according to the Stack Overflow Developer Survey, engineers’ confidence in the accuracy of AI-generated code fell from 42% to 33% between 2024 and 2025. Senior engineers are particularly skeptical, and there is a reason for this: AI-generated errors are often well hidden. The code looks clean and well thought-out at first glance, but the weak points lie deeper. It often takes experienced engineers to recognize them in the first place. Those who really understand code can also see what the AI has done wrong. <\/p>\n<\/div>

Where AI is actually used at BAYOOTEC<\/h2><\/div>

At BAYOOTEC, we use AI in a targeted manner rather than across the board. AI support brings us real added value in three areas. <\/p>\n<\/div>

Code review and security scanning:<\/h3><\/div>

AI-supported review tools help us to make security smells, anti-patterns and insecure dependencies visible directly in the pull request. A clear internal rule is important here: AI hints are never automatically flagged. They are input for human reviewers, not a replacement for them. An AI recommendation is a suggestion, not a commit. The designated person is always responsible, be it the lead software engineer or the security champion of a project <\/p>\n<\/div>

Test generation:<\/h3><\/div>

AI is good at writing tests, we are happy to leave that to it. People decide what is tested. Our QA team defines the relevant scenarios and the AI implements them. We read the fact that 89% of AI proposals go through the code review unchanged as a warning signal, not as a success metric. <\/p>\n<\/div>

Documentation and change logs:<\/h3><\/div>

AI helps us to explain code, generate API documentation and write change logs. This can save a lot of time, especially with larger refactoring cycles. However, in regulated projects and wherever customers explicitly check the documentation, the final approval always lies with experts. Versioned, traceable, audit-proof. <\/p>\n<\/div>

Where we consciously do without AI<\/h2><\/div>

The fact that we use AI does not mean that we use it everywhere. We do not use AI support in projects with particularly sensitive customer data or highly sensitive source code. In its impulse paper on GenAI and cyber security, Fraunhofer AISEC explicitly warns of the risk of information leakage through so-called inference attacks: anyone who transfers confidential data to a large language model can lose control of this information. <\/p>\n

In strictly regulated environments, i.e. where GDPR, EU AI Act, MDR or ISO standards must be complied with, we work with particular caution. The OWASP Top 10 for LLM applications lists prompt injection, insecure output and data leaks as critical risks. For security-critical components such as cryptography, authentication logic or access control, our general rule is: no automatic generation without dedicated manual checking and explicit approval. <\/p>\n

And we do not use AI where customers expressly do not want it. This is not a restriction for us, but a professional attitude. At a time when, according to the study “Future of Application Security in the Era of AI”, only 18% of companies have clear AI guidelines, but at the same time 81% knowingly provide insecure code, a conscious no to shortcuts is not a step backwards. It is the standard we set for ourselves. <\/p>\n<\/div>

Why AI code is not a free ride<\/h2><\/div>

AI-generated code looks clean. Often it is. But it can hard-code secrets or handle them insecurely, use crypto APIs incorrectly, introduce libraries without version or vulnerability checks, and implement input validation and authorization checks incompletely. Fraunhofer AISEC states it clearly in its impulse paper: Generative AI can improve engineering quality and speed, but the unchecked use of AI responses can create security vulnerabilities, especially if generated code is used in an uncontrolled manner. <\/p>\n

For this reason, we treat AI-generated code internally as “unaudited code”. This means that it goes through the same secure coding gates as any other code, sometimes with additional steps. In addition, we have formulated our own secure coding rules that explicitly address AI-specific failure patterns: insecure defaults, questionable library recommendations, missing boundary checks. <\/p>\n

This is not a mistrust of technology. It is quality assurance. <\/p>\n<\/div>

\"KI<\/span><\/div>

Our AI governance: Who decides what, and how<\/h2><\/div>

Analysis is not responsibility. That sounds simple, but it describes the core of the problem very precisely. AI can find weak points, make suggestions and prioritize risks. But risk appetite, policies and approval processes cannot be delegated. These are human decisions. <\/p>\n

At BAYOOTEC, we have established clear governance structures for this purpose:<\/strong><\/p>\n