Bkav shared an experiment in which one engineer used AI to complete a project in one week, compared with a traditional approach that the company described as requiring 10 engineers over eight months. This case points to an opportunity for employees to build their own tools for work, while raising a question: who is responsible when those tools access data and become part of operational workflows?
This information was published by the company itself, not as the result of an independent evaluation. The source also does not provide enough evidence to conclude that employees without a technical background could achieve similar results. Even so, the account shows the need to distinguish clearly between the speed of building an application and the conditions required to put it into use.
From an engineer’s experiment to opportunities for business staff
In an article about AI and productivity on Bkav’s website, the company stated that the cost of using AI in the experiment was three million dong, compared with a budget of three billion dong for the traditional approach.
This should not be understood as a complete comparison of total costs. The article does not provide details about the project’s scope, acceptance criteria, testing effort or maintenance. The cost of AI tools is not the same as the cost of completing and operating software.
The notable opportunity lies in the ability to narrow the gap between the person who understands the problem and the person who creates the solution. Business staff can describe a repetitive task, use AI to help write code, then test the tool before asking the technical team to develop it further.
Hypothetical examples include an operations employee creating a tool to standardize data tables, or a customer support employee building a search function for internal documents. These cases have a narrow scope, with inputs and results that can be checked against each other, making them more suitable for initial experiments.
An app built with AI assistance does not necessarily use AI at runtime
Two cases need to be distinguished. In the first, AI helps write code for conventional applications: forms, data filters or report-generation tools. In the second, an application calls an AI model during use to summarize, classify or answer questions.
The first case requires checks of the source code, processing logic and software security. The second also requires consideration of the data sent to the model, variability in its responses and the cost of each call. An application can fall into both categories.
This distinction directly affects acceptance testing. A calculation tool needs to produce correct results according to defined rules. A summarization tool needs to be checked for omitted important conditions or added information that is not in the document.
Business staff have the advantage of understanding exceptions in their work. But understanding a process does not automatically mean being able to detect permission errors, protect access keys or design a data recovery plan.
When a prototype becomes part of the system
Governance boundaries change when a tool no longer uses only simulated data. A prototype running on test files is different from an application that reads customer records, updates a sales system or sends external emails.
If employees set up connections using personal accounts, the business may find it difficult to determine which applications hold access permissions. When the creator changes roles or leaves the company, the tool may remain in use without anyone clearly responsible for maintaining it.
Risks also come from input content. For applications that use AI to read documents or emails, the text being processed may contain instructions intended to deceive the model. Data that has been read should therefore not automatically become grounds for expanding permissions or performing sensitive actions.
An important principle is to separate the AI’s recommendations from the system’s authorization of actions. The article on a control layer for AI action permissions helps clarify this approach. For internal tools, permission to read data should not implicitly include permission to modify or delete it.
Governance by risk level rather than a single approval process
The challenge is not simply whether to allow or prohibit employees from building their own applications. A suitable framework needs to distinguish low-risk experiments from tools that directly affect customers, finances or sensitive data.
A personal tool using simulated data can be tested in an isolated environment. When it is shared with the whole team or connected to real data, it needs an owner, a defined scope of access and someone to provide technical support. When an application is authorized to write data or send information externally, testing and approval requirements must be stricter.
The IT department therefore retains an essential role: providing approved environments, managing credentials and checking critical connections. Business staff define requirements, check actual results and report exceptions.
Testing needs to include failure scenarios: files with missing columns, duplicate data, conflicting documents or users without permission. The perspective on testing with a separate account is also useful when separating the test environment from live operations.
Operational efficiency still needs to be demonstrated
The information published by Bkav does not fully address the project’s stability, scalability or ongoing maintenance costs. This case therefore cannot be used to infer a general level of savings for every business or every group of employees.
For employee-built applications, a useful measure is not just the time it takes to create a prototype. It also needs to account for time spent checking outputs, fixing errors, supporting users and handling incidents. A tool that generates reports quickly but requires every row to be checked again may not yet save effort.
Operating costs also include storage, service connections and handover to the next person responsible for maintenance. This is also the gap between being able to create a solution and being able to deploy it, discussed further in the article AI and the execution bottleneck.
The opportunity for employees to build their own applications lies in using their business knowledge to test solutions faster. Long-term usability, however, depends on testing evidence, limited access permissions and clear operational responsibilities—factors that cannot be replaced by coding speed alone.