AI is not the problem. Irresponsible implementation is.

Artificial intelligence is no longer a topic of the future. It is already in business, in marketing, in websites, in automations, in applications, in customer support, in content generation and, increasingly, in software development.

And that is not a problem.

The problem arises when people confuse access to AI with competence. Just because you can generate code with AI does not automatically mean you know how to build software. Just because you can generate a landing page does not mean you understand security, GDPR, infrastructure, personal data, deployment, testing, or maintenance. Just because a tool gives you a result in a few minutes does not mean that result can be put directly into production, connected to real systems, and used by real customers.

This is where the less spectacular, but much more important part comes in: responsibility.

At Dalbe, we use AI. We use it for ideas, structure, analysis, texts, code, automations, documentation, checks, and efficiency. But the essential difference is that we use it as people who have experience in software, e-commerce, SEO, security, data, and digital processes. AI helps us work faster, but it does not replace technical judgment. And nor should it.

In short

• AI can speed up work, but it does not replace technical competence.
• AI-generated code must be checked, secured, tested, and deployed correctly.
• Personal data must never be exposed in the frontend or in public code.
• A real automation means more than just a demo generated in a few minutes.
• In the coming years, testing and verification will become more important, not less important.
• AI must be used with clear rules, especially when it touches data, clients, or real business processes.

What happened this week

In the same week, we had three different situations that show very clearly where we are with AI in practice. Not in theory. Not in beautiful presentations. Not in articles that say AI will change everything, as if that hasn't already been said about every new technology of the last 25 years.

The first situation: several projects carried out with AI integration through Google AI Studio were attacked. We were not hacked. The systems were not compromised. Client data was not exposed. But we clearly saw an increase in abuse attempts.

The attackers tried to force the systems, and in the process, a portion of the integrated AI tokens were consumed before the problem was caught, flagged, and stopped together with Google's protection mechanisms.

The conclusion is simple: when AI is integrated into a real application, we are no longer talking about playing. It is no longer just a prompt in an interface. It becomes part of a software system, with costs, limits, access, security, monitoring, and responsibility.

An AI system integrated into an application must be treated like any other exposed resource: with limitations, monitoring, logs, alerts, and the ability to quickly cut off access when suspicious behavior occurs. If these things don't exist, costs can rise before anyone notices the problem.

The second situation: for a client we cannot name, another company implemented a landing page. The fact that the landing page looked AI-generated was not the problem. We have nothing against using AI. The problem was that the implementation clearly showed that the team in question did not understand fundamental software development concepts.

In the frontend code, information was hardcoded that had no business being there: logic elements, the location where data is saved, and areas related to personal information. For the non-technical, the translation is simple: risk of data leak, risk of GDPR violation, and serious image risk for the client.

An .env file is normally used to keep sensitive configurations separate: API keys, connection data, private endpoints, or other information that should not reach public code. When such information is placed directly in the frontend, it can become visible to anyone who knows where to look.

If we had connected that landing page directly to our system without checking, the client could have ended up in a very unpleasant situation. Not because AI was used, but because the result was treated as a final product without a competent person checking it.

We explained the situation to the client, remade the component, and deployed it correctly. This was possible because we use AI, but we also have knowledge of programming, security, and implementation. The difference is big. Sometimes the difference between "looks like it works" and "is safe to put into production" is exactly the part the end-user doesn't see.

The third situation was more human, and therefore obviously more tiring. A person came to the office for an offer. It was about automation. We estimated approximately 8 hours of work, at a cost of 500 EUR + VAT. The reaction was furious. The person told us that they know AI, that they saw that such things can be done in a few minutes, and that it is not normal for us to need a day.

They left angry.

They probably weren't the right client for us. And that's okay. Not every lead has to be transformed into a client. Sometimes the best project is the project you don't take.

AI can generate code. But generated code is not automatically good software.

In 2026, anyone can try to write code with AI. The more important question is: should anyone put that code into production?

The honest answer is: not without verification.

AI can generate a function, a page, a form, a script, an automation, or even a seemingly functional application. But a real application doesn't just mean code that runs once on a laptop. A real application must be deployed correctly, secured, tested, monitored, and designed for edge cases.

What happens if the user enters the wrong data? What happens if a bot attacks the form? What happens if the API responds slowly? What happens if someone tries to abusively consume AI tokens? What happens if personal data is visible in the frontend? What happens if the API key becomes public? What happens if an automated workflow sends the wrong information to the client?

These questions are not details. They are the difference between a demo and a real system.

AI can help a lot in generating code, but it doesn't take responsibility for what happens next. It doesn't go to the client to explain the data leak. It doesn't respond to GDPR notifications. It doesn't pay the costs generated by an abused API. It doesn't repair the company's image after a poorly implemented landing page exposes personal information.

The responsibility remains with humans.

A demo is not the same as a functional solution

This is one of the biggest confusions created by AI: people compare the time needed to generate a demo with the time needed to deliver a functional solution.

A demo can take a few minutes. A solution that must function correctly for a real business requires analysis, verification, integration, testing, and assumption of responsibility.

When we estimate 8 hours for automation, we are not saying that writing the first draft of code takes 8 hours. We are saying that a usable, verified, and business-appropriate result can take 8 hours.

You can ask AI to generate a script for you in 3 minutes. But who checks if the script handles the wrong cases? Who connects it to existing systems? Who ensures that data is not exposed? Who checks the logic? Who tests the real scenarios? Who fixes the problem when something doesn't work? Who takes responsibility towards the client?

AI can reduce execution time. It doesn't eliminate the need for competence.

This is a difference the market will have to learn. Sometimes the easy way. Other times after a few costly incidents, because apparently that's how civilization learns best.

Why testers will become increasingly important

We see more and more apps, landing pages, and automations generated quickly with AI. Some are useful. Some are acceptable. Others are a beautifully dressed disaster.

For this reason, we believe that the role of the tester will become one of the most important roles in the coming years.

We are not just talking about classical testing, in the sense of "press the button and see if it works". We are talking about people who understand the product, the user, the risks, the data flows, edge cases, basic security, and the impact of an error on the business.

The more AI produces code, texts, automations, and interfaces, the more important verification will become. If production becomes faster, quality control must become more serious. Otherwise, we just produce mistakes faster.

A good tester will not just be the person who finds bugs. They will be the person who asks the uncomfortable questions before the problem reaches the client.

• Where is the data saved?
• Who has access to it?
• What happens if the form is attacked?
• What happens if the AI responds incorrectly?
• What happens if the user enters unexpected data?
• Are there consumption limits?
• Are there logs?
• Are there kill switches?
• Is there human verification where needed?

These questions don't kill innovation. They make it usable.

The problem is not that AI is used in marketing

Let's be clear: it is not wrong for a marketing agency to use AI. It would even be weird not to use it in 2026. AI can help with texts, ideas, layouts, messages, ad variations, landing page structure, audience analysis, and many other things.

The problem arises when a team that does not understand the technical side starts delivering technical components as if they were secure products.

A landing page that collects data is not just design. It is an entry point into a system. If that form collects names, emails, phones, preferences, or other personal data, we are already entering the GDPR area. If that data is saved incorrectly or exposed in the frontend, the problem is no longer aesthetic. It is legal, technical, and reputational.

This is where the difference between "looks good" and "is well made" is seen.

A non-technical client has no way of knowing what an .env file is, where API keys should be kept, why sensitive data shouldn't be hardcoded in the frontend, or why business logic shouldn't be exposed publicly. The client pays specialists precisely so that these things are thought out correctly.

If the specialist doesn't know, AI won't save them. Often it just gives them a convincing enough result that the mistake looks professional.

Romania is behind, but the risks don't wait

In Romania, many companies are still behind in digitization. Some do not have clear processes, do not have a CRM used correctly, do not have clean data, do not have internal procedures, do not have a real strategy for website, SEO, automation, or customer support.

Then AI comes along and everyone hopes the problem will be magically solved.

It won't be solved.

AI does not fix chaos. It usually accelerates it.

If the data is wrong, the AI will work with wrong data. If the process is unclear, the AI will automate an unclear process. If the team doesn't know what it's checking, the AI will produce results that seem good but can be completely wrong. If no one takes responsibility, AI becomes a convenient excuse.

At the same time, those committing abuses are not waiting for the market to mature. We see more and more fraud attempts, fake content, fake ads, automated messages, deepfakes, quickly built pages, and mechanisms that exploit the lack of digital education. While some companies are still wondering if AI is worth using, scammers have already integrated it into their processes.

This is one of the reasons why responsibility is no longer optional. If we use AI in business, we must also understand the risks.

The AI Act changes the discussion

At the European level, the AI Act entered into force on August 1, 2024. Some obligations already apply, including those related to AI literacy and prohibited practices, starting February 2, 2025. Full application comes progressively, with important deadlines in 2026 and 2027.

For companies, the message is quite clear: we can no longer treat AI as a toy without rules. If a company uses AI in processes, products, decisions, automations, or interactions with users, it must understand where it uses it, what data it processes, who verifies the results, and who is responsible for the effects.

This does not mean that every small business must become a legal department overnight with servers in the basement. But it does mean there must be a minimum of common sense and control.

In other words: józan paraszti ész. Practical common sense.

If AI touches personal data, it must be treated seriously. If AI generates decisions or recommendations that affect people, it must be verified. If AI is integrated into a software product, it must be secured. If AI writes public content, it must be checked for accuracy, tone, promises, and sources. If AI is used by employees, the team must know what they are and are not allowed to do.

AI literacy doesn't just mean knowing how to write a nice prompt

AI literacy means understanding the limits of AI, the risks, the data you input, the results you must verify, and the situations where AI should not be used without human oversight.

In a company, this can mean simple but important rules:

• what data we never enter into an AI tool;
• what results must be checked before publication;
• what tools are approved for the team;
• who is responsible for AI automations;
• where AI is allowed and where human verification is needed;
• how we handle personal, commercial, or confidential information;
• what we do when the AI makes a mistake.

It is not necessary for every employee to become an expert in machine learning. But it is necessary for them to understand that AI is not a rule-free space.

What the responsible use of AI in a company means

The responsible use of AI doesn't mean slowing down innovation. It means not confusing speed with progress.

A company that wants to use AI correctly should start with simple questions:

• What concrete problem do we want to solve?
• Can we measure the result?
• What data do we use?
• Is it personal or sensitive data?
• Who verifies the AI result?
• What happens if the AI makes a mistake?
• Where does the automation stop and the human intervene?
• What costs can the system generate?
• How do we prevent abuse?
• Who is responsible for maintenance?

These questions seem simple. That is precisely why they are ignored so often.

In a software project with AI, consumption limits, authentication, abuse protection, logs, monitoring, error messages, fallbacks, testing, and clear procedures for situations where something goes wrong must be considered.

In an AI marketing project, promises, sources, the legality of statements, how data is collected, and the impact on the client's image must be checked.

In an e-commerce project, it must be verified that the AI does not invent product benefits, does not create misleading descriptions, does not generate unvalidated medical or technical claims, and does not affect legal compliance.

Minimum checklist before putting an AI project into production

Before an AI project is connected to real data, real clients, or real business processes, at least the following things should be checked:

• Is there authentication and access control?
• Are there consumption limits for APIs and tokens?
• Are there logs and monitoring?
• Are there alerts for suspicious behaviors?
• Is personal data saved correctly and protected?
• Are API keys and sensitive configurations kept in the backend or in environment variables?
• Have wrong cases been tested, not just the ideal scenario?
• Is there a fallback if the AI responds incorrectly or doesn't respond?
• Is it clear what the AI does and what the human verifies?
• Is there a person responsible for verification and maintenance?

This checklist does not solve all problems, but it is a healthy start. And honestly, it's already more than we see in some projects delivered with a lot of confidence and little verification.

What companies should do before implementing AI

Not all companies need complex AI projects. Often, the first step is much simpler: understanding where AI can bring value without creating unnecessary risks.

A healthy start might look like this:

• identifying repetitive processes;
• establishing areas where AI can help without access to sensitive data;
• defining internal rules of use;
• training the team;
• testing on small processes;
• measuring the time saved;
• checking the quality of the results;
• gradually expanding only where there are real results.

A minimal internal AI policy can be very useful even for a small business. It doesn't have to be a complicated document. It just needs to clarify the essentials:

• what tools can be used;
• what data is never entered into AI;
• what types of results must be checked by a human;
• who approves public content;
• who is responsible for automations;
• what happens in case of an error;
• how important processes are documented.

It's less spectacular than saying your company is "AI-powered", but it's infinitely more useful.

How we see AI at Dalbe

For us, AI is not magic. It is a tool. A very powerful tool, but a tool nonetheless.

As a team that develops websites, online stores, mobile apps, and automations, we see AI from a very practical area: not as a presentation, but as a system that must work for real clients.

We use it where it helps: in structuring ideas, in analysis, in generating variants, in documentation, in debugging, in SEO, in texts, in planning, in automations, and in reducing repetitive work.

But we don't use it as an excuse for lack of thought. We don't put code into production just because it "was generated by AI". We don't connect forms without checking where the data goes. We don't treat security as a detail. We don't consider a landing page finished just because it looks good. We don't promise the client that everything is done in a few minutes just because a demo looks nice.

From the projects we develop and maintain, we increasingly see the same difference: AI can quickly produce an initial version, but the final quality depends on the people who verify the architecture, the security, the data, and the real use scenarios.

AI can accelerate the work of a good team. But it can amplify the mistakes of an unprepared team.

That is why we believe the coming years will not just be about who uses AI. They will be about who uses it responsibly, measurably, and with enough competence that the result does not become a risk for the client.

Conclusion

AI is not the problem. Irresponsible implementation is.

It is not wrong to use AI for code, marketing, automations, or content. What is wrong is delivering unverified results, exposing data, ignoring security, not understanding what you've generated, and selling the client the impression that a real system is built in a few minutes.

In business, speed is important. But trust is more important.

Software must work, but it must also be secure. A landing page must look good, but it must handle data correctly. Automation must save time, but it must be controllable. An AI system must help people, not create problems that no one knows how to fix.

If you have an automation, a landing page, an application, or an AI flow that you want to use in business, it is worth checking before connecting it to real data or real clients. Sometimes a simple technical check can prevent much more expensive problems.

AI is useful when it is used smartly. With process. With verification. With testing. With responsibility. And, perhaps most importantly, with common sense.

Because ultimately, technology changes. Tools change. AI models change.

Technology changes. Tools change. AI models change. But practical common sense remains mandatory.

Useful sources

• European Commission: AI Act regulatory framework
• European Commission AI Act Service Desk: implementation timeline