"Many cases take a technology-centric approach. They think data is all they need and do not think much about data-related complexity. Combined with provider-centric design, companies are failing to deliver results in line with their AI investment."

Han Sun-ho (한선호), vice president and chief AI officer at Bespin Global, summed up the reasons many companies still do not feel the impact of their AI investment in those terms.

In a keynote speech at Bespin Global's AI Partners Day 2026 event held on March 31, Han stressed: "AI is not a technology issue but a management issue. IT teams and AI teams should not move separately. We need a process that communicates with partners who properly understand the technology while building internal capabilities at the same time. Companies that delivered results with AI did so not because they used good technology, but because they defined the problem properly."

A technology-centric approach, he said, means using a good tool first and looking for a problem later. He explained that fear of falling behind if they do not know the technologies attracting market attention is driving technology-first approaches.

On this, Han cited text-to-SQL as a representative example, where AI retrieves information from a database in real time when asked in natural language.

He said text-to-SQL allows employees to receive the data they want within 2 to 5 minutes without asking the IT team. He said the process used to take as little as a week and as long as 2 weeks. The technology itself is powerful, he said, but it is not free of accuracy issues.

Text-to-SQL follows the multiplication rule, he said. When you multiply accuracy by stage, such as 95 percent for understanding user intent, 95 percent for data retrieval, 90 percent for SQL generation and 99 percent for answer generation, actual accuracy falls to about 80 percent, he said.

He said: "The No. 1 model on the leaderboard records 95.8 percent in a specific environment, but remains at 65.8 percent in the actual Korean enterprise environment. If it cannot exceed 90 percent, it is hard to apply in the field. It should be used only when truly necessary."

He presented defining the problem first and choosing the technology next as a solution. "First, determine whether a specific task has a real impact on the business," Han said. "Then select the technology with the best cost-performance for solving that problem. If the order is reversed, you end up with a system that spends money without effect."

Data complexity is another area companies often overlook in AI projects. He said it is also unrealistic to think it ends with building a vector database by starting businesses for parsing, which converts data into a form AI can read, and chunking, which splits transformed text into fixed sizes.

Han said a vector database is a technology that represents unstructured data in multidimensional space and finds the closest answer based on probability. It is useful, he said, but it does not guarantee an absolute correct answer and has structural limitations.

He cited four problems with vector databases: they cannot handle multidimensional relationships and hierarchical structures; it is difficult to process structured and unstructured data together; when domain-specific terms collide at the chunk level, 'hallucination' can occur as AI inserts incorrect information; and they cannot do complex reasoning.

He suggested graph databases and an ontology-based approach as technologies to compensate for the limits of vector databases.

He said that in a real insurance company case comparing vector and graph approaches, the graph approach structurally connected relationships among products, riders and diseases to deliver only accurate information to a large language model. He added that in manufacturing sites, a company that built supply data with a domain-specific ontology produced real effects through step-by-step feedback. "A lot of data is not necessarily good," he said. "The structure has to fit."

On provider-centric design, Han said the problem is building systems from the perspective of the builders rather than actual users. "Even if it is technically impressive, works well in demos and gets applause in executive presentations, it means nothing if the business side does not use it," he said, citing a logistics company case.

The company upgraded its warehouse management system by linking multiple solutions based on an ML model. Executives expected success. But customer experience collapsed completely in the final 1 km segment where deliveries are made to customers.

Han said customers wanted to receive goods at the time they wanted and track deliveries in real time, but the system did not design for that. He said it focused only on provider efficiency and did not look at customer pain points. He also stressed that what appears to be a problem is mostly a symptom, and that instead of taking painkillers for a headache, companies must dig into why it hurts. He said even if team leaders gather to pick 10 use cases and narrow them to 3 to start, results will not follow unless they begin from problems the business side actually experiences. He added that time should be spent finding the right task, looking for root causes rather than visible problems and starting with cases linked to business impact. He also said companies should start small rather than use a big-bang approach, verify with real data and expand step by step. He added that time spent diagnosing and monitoring is more important than time spent building AI agents.