Generative AI can only work with the data you give it. When that data is wrong, outdated or duplicated, the model repeats those flaws in fluent sentences that sound right.

The numbers show how common the gap is. A Gartner survey of 1,203 data management leaders found that 63% of organizations either lack the right data management practices for AI or are unsure they have them. Gartner also predicts that through 2026, organizations will abandon 60% of AI projects that lack AI-ready data. Earlier, Gartner forecast that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, and it named poor data quality among the causes.

This guide explains what data quality for generative AI means, which dimensions to check, where problems hide, and how to fix and measure them. You will get four tables, a 7-step framework and a metrics list for your next project review.

SotaTek is an AI & Blockchain Innovation Partner. We support enterprises with AI readiness assessments, use case prioritization, AI roadmaps, PoC development, integration and responsible scaling, so your generative AI starts on data you can trust.

What Is Data Quality for Generative AI?

Data quality for generative AI is how well the data a model learns from or retrieves fits one specific task. Good data is accurate, complete, current, unique, representative and safe to use. Gartner adds that AI-ready data has to cover the real use case, including its normal patterns, errors and outliers. Data that works for one use case can fail in another.

Traditional data quality asks if a record is correct. Generative AI asks more, because the model reads text and documents and turns them into new content. A wrong value in a report stays in one cell. A wrong paragraph in a knowledge base can appear in thousands of answers.

Gartner also notes that AI-ready data is not a one-time job. The practice needs steady improvement as new AI use cases arrive.

Why Data Quality for Generative AI Matters More Than Model Choice

Teams often compare models first and inspect data last. Research shows why that order backfires.

• Duplicates raise memorization. A peer-reviewed ACL 2022 paper found that many language modeling datasets hold near-duplicate examples, and that over 1% of unprompted output from models trained on them was copied verbatim. After deduplication, models emitted memorized text ten times less often. Train-test overlap also touched over 4% of validation sets, which can make test scores look better than real performance.
• AI-written text can degrade later models. A Nature study found that indiscriminate training on model-generated content causes irreversible defects, where rare parts of the original data disappear. The authors call this model collapse. It matters when teams fine-tune on LLM-written examples without filtering them.
• Bad source documents produce bad answers. In a retrieval-augmented generation (RAG) system, the model builds its answer from retrieved pages. If a page is outdated or wrong, the answer will be too, even with a strong model.

The business effect is easy to miss until launch. One wrong answer can make users stop trusting the tool, which is one way a pilot that looked good in a demo stalls afterward.

The 8 Dimensions of Data Quality for Generative AI

Use these dimensions as an audit checklist. Rank them by use case, because they do not carry equal weight.

A legal assistant needs freshness and provenance first. A multilingual support bot needs representativeness first. Pick the top three for your use case and set pass or fail rules for each.

For multilingual use cases, test each language on its own. An average score across languages can hide a weak one, so write golden questions in every language you serve.

Where Data Quality for Generative AI Breaks: The Four Data Layers

Most enterprises do not train a model from scratch. They start with a foundation model and add their own data in three places. Each layer fails in a different way.

For most business teams, the retrieval corpus needs the most work. Gartner lists chunking, embeddings and RAG integration among the AI-specific additions to existing data management. These are data quality decisions, not only engineering choices.

Picture a bank help assistant that retrieves from a policy library. The library holds three versions of one fee policy. The retriever picks the oldest because its wording matches the question best. The model answers fluently and wrongly. A model upgrade will not fix that. Version control and a freshness filter will.

How much of this stack you can inspect depends on your build path. SotaTek's guide to custom AI vs off-the-shelf AI compares cost, speed, control and fit, and that choice decides which layers you can fix yourself.

A 7-Step Framework for Data Quality for Generative AI

Gartner outlines five steps to make data AI-ready: align data to use cases, set governance needs, make metadata active, prepare pipelines, and assure data through testing and monitoring. The framework below adapts those ideas into seven working steps for generative AI teams.

1. Define the use case and a good answer. Write a few dozen real questions or tasks with expected outputs. This sets the quality bar.
2. Inventory and profile the data. List sources, owners, formats and update cycles. Profile for duplicates, empty fields, date ranges and language mix.
3. Clean and normalize. Remove exact and near duplicates, repair broken tables, standardize terms and retire outdated versions.
4. Add metadata and lineage. Tag each item with owner, date, version, source, sensitivity and access level. Active metadata lets retrieval filter by freshness and permissions.
5. Set quality gates. Block data that fails rules before it reaches an index or training set. Typical rules are PII scans, duplicate checks, date checks and parsing tests.
6. Build a golden set and test. Hold out questions with expected answers and source documents. Rerun them after every data change.
7. Monitor and fix in production. Track freshness, retrieval hits and user feedback, then send failures back to data owners. Gartner recommends DataOps and data observability to track patterns and changes.

Here are sample quality gate rules for a RAG index:

• Reject any document without an owner and a last-reviewed date.
• Flag documents with near-duplicates for human review.
• Fail files where table text is missing after parsing.
• Hold back chunks that contain PII until it is masked or removed.
• Exclude draft and archived versions by default.

Rules only work when someone owns them. Give each data domain a named owner who fixes failures. Let domain experts write and review the golden set. Let engineers run the gates and dashboards. Gartner advises data leaders to work with legal and business teams on governance needs, including how sensitive data is detected and protected.

Monitoring has a cost. SotaTek's AI development cost guide suggests budgeting 15% to 30% of the build cost per year for monitoring, retraining, security updates and prompt tuning. Treat data upkeep as part of that line item.

How to Measure Data Quality for Generative AI

You cannot manage what you do not score. Track data metrics and output metrics together, because a clean-looking dataset can still retrieve badly.

Set thresholds per use case. A financial or medical assistant needs tighter limits than an internal brainstorming tool. Review the numbers after every major data change, not once a quarter. Evaluation also needs an owner. SotaTek's AI agent development process lists evaluation ahead of deployment, governance and optimization.

Mistakes to avoid

• Cleaning once and never again.
• Judging data by volume instead of fit for the use case.
• Letting an LLM write or label data with no human sampling.
• Indexing a whole shared drive, including drafts and old versions.
• Skipping access metadata, so retrieval ignores who may see what.

Conclusion: Make Data Quality for Generative AI a Release Gate

Generative AI is only as dependable as the data behind it. Check four layers, score eight dimensions, follow seven steps and measure with a golden set. Treat these checks as a gate before launch, then keep them running after it.

Planning a generative AI project Consult SotaTek on an AI readiness assessment and a data quality plan before you build.

South Korea’s domestically developed AI semiconductor technology is set to enter Vietnam’s rapidly growing AI market. On October 20, 2026, DeepX, a South Korean AI semiconductor company, and SotaTek Korea, a Vietnam-based global IT services and consulting provider, signed a Memorandum of Understanding (MoU) at Gangneung Olympic Park during the 2026 Gangneung ITS World Congress. Through this partnership, the two companies aim to introduce Neural Processing Unit (NPU) technology to Vietnam, initially through education initiatives, while exploring opportunities to expand AI Vision and Physical AI applications across government, public services, and manufacturing.

[Group photo at the 2026 ITS World Congress. From left: DeepX representatives, President of the Korea Intelligent Transport Systems Association, Vice Minister of Vietnam’s Ministry of Construction, and SotaTek Korea representatives.]

Vietnam’s Growing AI Market Creates New Opportunities for NPU Technology

Vietnam is strengthening its position as an AI research, development, and application hub in Southeast Asia. Under its national AI strategy, the Vietnamese government aims to develop the country into a leading center for AI research, development, application, and value creation in ASEAN and Asia by 2030. The strategy also emphasizes strengthening national capabilities in AI research, technological autonomy, adoption, and governance.

As AI adoption continues to expand across education, public services, and industrial operations, demand for efficient AI computing infrastructure is expected to grow. Against this backdrop, DeepX and SotaTek Korea plan to introduce DeepX NPU products, including the DX-M1, to the Vietnamese market and identify potential business opportunities.

NPU technology is designed to accelerate AI workloads through specialized processing architecture. By enabling AI inference directly on devices, it can support applications that require efficient computing, low latency, and reduced reliance on cloud infrastructure. These capabilities are relevant to emerging applications in AI Vision, industrial automation, and Physical AI.

Education as the First Step Toward Building a Physical AI Ecosystem

Education will be the initial focus of the partnership. DeepX and SotaTek Korea plan to collaborate with leading Vietnamese universities that offer AI-related programs to develop specialized talent and strengthen practical knowledge of AI semiconductor technology.

The initiative is intended to provide students and future engineers with opportunities to learn about and work with DeepX NPU technology. By establishing an educational foundation, the two companies aim to contribute to the development of a local talent pool capable of researching, developing, and operating AI-based systems.

Building on this cooperation, the partners will explore opportunities to expand into government, public services, and manufacturing. Potential application areas include AI Vision and Physical AI solutions for surveillance and security, industrial safety management, and quality inspection.

These applications reflect the growing role of edge AI and AI-enabled devices in connecting intelligent algorithms with real-world environments. The partnership seeks to combine semiconductor technology with software development and system integration capabilities to explore solutions suited to Vietnam’s market needs.

Complementary Roles in Technology, Education, and Market Development

Under the MoU, DeepX and SotaTek Korea will contribute complementary capabilities to the partnership.

DeepX will provide NPU products, develop educational content, and support marketing activities related to the initiative. SotaTek Korea will lead local coordination, including recruiting participating universities, managing program operations, providing maintenance support, and overseeing overall business activities.

The companies plan to work with Vietnamese universities and relevant institutions to expand the educational program. The initiative will operate based on minimum actual costs associated with each party’s responsibilities, with the aim of supporting broader participation from local academic institutions.

The agreement was signed in the presence of key representatives from both companies and the Korea Intelligent Transport Systems Association, as well as representatives from Vietnam’s Ministry of Construction. The signing took place during the 2026 Gangneung ITS World Congress, an international event bringing together stakeholders in intelligent transport systems and related technologies.

[DeepX and SotaTek Korea sign an MoU to explore opportunities for bringing AI semiconductor technology to Vietnam.]

DeepX and SotaTek Korea Share Their Expectations for the Partnership

Kang Sang-kyun, Executive Director of Sales at DeepX, highlighted SotaTek’s global service capabilities and AI expertise as important strengths for the collaboration.

“ SotaTek’s global service and support capabilities are among the best. In particular, we expect its AI expertise to make the company an important partner in developing various solutions and applications based on DeepX NPUs, as well as integrating and applying these technologies in practical environments. Through this collaboration, we look forward to expanding our presence in the Vietnamese market,” he said.

Jeon Tae-sik, Chief Strategy Officer of SotaTek Korea, noted the growing demand for AI technologies in Vietnam and emphasized the importance of developing local talent.

“Demand for AI in Vietnam is growing rapidly. Through our strategic partnership with DeepX, a company at the forefront of Physical AI, we aim to expand our market presence while working with leading universities to develop and secure a strong pipeline of specialized talent,” he said.

Partnership Roadmap and Next Steps

Following the signing, the two companies outlined an initial implementation timeline. They planned to finalize the participating universities and budget by November 1, 2026, and complete university recruitment by November 30. Product delivery was scheduled for January 1, 2027, followed by the program launch ceremony on February 1, 2027.

Through this phased approach, DeepX and SotaTek Korea aim to establish an initial foundation in AI education before exploring broader opportunities for NPU adoption in Vietnam. The collaboration also reflects the potential of Korea–Vietnam technology partnerships to connect AI semiconductor innovation with local software development, system integration, and industry requirements.

About DeepX

DeepX is a South Korean fabless semiconductor company specializing in the research and development of high-performance, low-power AI semiconductors optimized for on-device AI. Its NPU solutions are designed to bring AI computing capabilities to devices and systems across a range of industrial and commercial applications.

About SotaTek Korea

SotaTek Korea is part of SotaTek, a global IT services and consulting company headquartered in Vietnam. Backed by a team of more than 1,500 IT professionals, SotaTek provides software development, AI solutions, and IT consulting services to clients across international markets.

• Structured data lives in fixed schemas such as tables, columns and data types. Unstructured data (documents, emails, images, audio, video) has no schema, and it makes up most enterprise data.
• Structured data suits classic machine learning. Unstructured data needs deep learning, language models or computer vision, plus extra preparation such as embeddings.
• Neither type is better. Structured data gives AI precise facts. Unstructured data gives it the context behind those facts. Most useful enterprise AI needs both.
• Three architecture patterns connect the two: hybrid RAG, a lakehouse and real-time pipelines. Shared keys, such as a customer ID, make the link work.
• The biggest risks are quiet ones: mismatched access rules, hidden personal data and outdated documents.

Most AI projects do not fail because of the model. They fail because of the data behind it. Gartner found that 63% of organizations either lack the right data management practices for AI or are unsure they have them, and it predicts that organizations will abandon 60% of AI projects unsupported by AI-ready data through 2026. The data mix adds to the problem. IDC estimates that unstructured data makes up over 90% of enterprise data and grows three times faster than structured data, yet less than 1% of it is used in generative AI today.

That is why structured vs unstructured data for AI is a practical question for any AI team, not a vocabulary lesson. This guide explains what each type is, how they differ, how AI models use them, which one fits your use case, how to combine them in one architecture and what to check before you build.

SotaTek, an AI & Blockchain Innovation Partner, supports enterprises from data readiness and workflow integration to scalable deployment and governance-ready implementation, so the data you already hold can feed AI that works in production.

What Is Structured vs Unstructured Data?

Structured data is information stored in a fixed format with defined fields, types and relationships. Think of rows and columns in a relational database: customer records, transactions, inventory counts and timestamped sensor readings. Every field has a name and a type, so a query like "total sales by region last quarter" returns an exact answer.

Unstructured data has no predefined schema. It includes emails, PDFs, contracts, call recordings, chat logs, scanned forms, images and video. The information is there, but a model has to interpret it before a system can use it.

Semi-structured data sits between the two. JSON files, XML, server logs and email headers carry tags or keys, but the fields can change from one record to the next. Teams often use this type as a bridge. You can parse it into tables or index it next to your documents.

Here is a quick test. If you can run a SQL query on the data without extra processing, it is structured. If you need a model to read it first, it is unstructured.

Structured vs Unstructured Data: Key Differences That Matter for AI

The two types differ in more than format. They change how you store data, which models you pick, how much preparation you need and where quality problems hide.

Two rows deserve extra attention.

The first is labeling. People can read a sentence or look at an image and judge it, so teams can label unstructured data and compare a model against human-level performance, as DeepLearning.AI explains. Tabular data is harder for people to judge, and models trained on it often beat humans, which makes that benchmark less useful.

The second is preparation effort. TDWI notes that structured data can often go into a model directly, while unstructured data needs preprocessing to extract features and patterns first. Plan your timeline around that gap.

How AI Uses Structured vs Unstructured Data for AI

Structured data powers the AI most businesses already run. TDWI lists fraud detection on transaction records, demand forecasting on sales data and customer segmentation on demographic and purchase data as typical examples. For these tasks, you often do not need a deep neural network. A NeurIPS 2022 benchmark by Grinsztajn and colleagues found that tree-based models such as XGBoost and random forests remained state of the art on medium-sized tabular datasets of around 10,000 samples.

Unstructured data needs a different toolkit. Language models can read, summarize, classify and extract information from text, and computer vision models do the same for images, as TDWI describes. The key technique is the embedding. A model turns a paragraph, an image or an audio clip into a list of numbers so that similar items land close together. A vector database then finds the closest matches. This is how retrieval augmented generation (RAG) pulls the right passage from thousands of PDFs before a model writes an answer.

Each type also has a weak spot:

• Structured data cannot explain itself. A table can show that churn rose, but not why. Support transcripts and survey comments can.
• Unstructured data is a poor source for exact numbers. A language model is not a calculator or a database. StackAI points out that structured systems are where agents compute precise answers, filter reliably and reconcile totals.

Cost follows the same split. A model on tabular data often trains on modest hardware. Unstructured pipelines add OCR or transcription, embedding for every document, vector storage and larger models at query time. Budget for that compute early, and index only the sources the use case needs.

Turning unstructured inputs into structured records is a common first step. SotaTek's guide to AI automation services covers AI-powered data processing in more detail.

Structured vs Unstructured Data for AI by Use Case: Which One Fits?

Neither type is better. The right choice depends on the question you want the AI to answer.

• Start with structured data when the answer is a number, a score or a forecast and you have clean history.
• Start with unstructured data when the answer lives in language, images or sound, such as search, summarization, classification or visual inspection.
• Use both when you need a precise fact and the reason behind it.

The table below shows how this plays out across four industries.

Real deployments follow the same logic. TechTarget describes a healthcare provider that uses an AI agent to review unstructured medical records and check whether a patient meets therapy qualification criteria. It also describes an insurance case where a platform linked a $525,000 kitchen-fire claim to a similar claim from two years earlier, a match that structured data alone would have missed. For more examples, browse SotaTek's list of AI automation use cases.

Three mistakes show up often. Teams ask a language model for a number that a SQL query would return exactly. They index documents with no metadata, so the model cannot tell a current policy from an old one. And they assume structured data is already clean. StackAI warns that structured data often hides quiet, systematic errors that can be just as damaging as messy documents.

Combining Structured vs Unstructured Data for AI: Three Architecture Patterns

Most enterprise AI needs both types. According to Sombra, structured data supplies precise, verifiable facts, while unstructured data supplies the context and explanations behind them. Teams usually connect the two in one of three ways.

TechTarget warns that separate systems often query each data type, which leaves the two unconnected. The fix is the linking step. Store shared keys, such as customer ID, product code or claim number, as metadata on every document chunk. A question about one customer can then pull the account record and the relevant emails together.

Illustrative example. A customer asks, "Why is my refund late?" The router sends two requests. A SQL query returns the order status, the refund date and the payment method. A vector search returns the refund policy and the last two support emails. The model combines both into one answer: the refund left the account on a set date, and the policy explains how long the bank takes to post it. Neither source could answer alone.

Do not build a hybrid system when one source answers the question. A demand forecast from sales tables does not need a vector database.

Structured vs Unstructured Data for AI Readiness: A Pre-Build Checklist

Data readiness is where many projects are won or lost. Sombra defines AI-ready data as data that is clean, integrated, well governed and accessible in the right format and context. Each type reaches that bar differently. Structured data needs deduplication, complete fields and consistent definitions. Unstructured data needs current versions, clear ownership and metadata a model can filter on. Readiness also shapes cost. SotaTek's AI automation cost breakdown lists data readiness among the factors that make AI automation cost hard to estimate. Use this checklist before you pick tools.

1. Inventory both types. List every source, owner and format. Mark which ones the use case needs.
2. Match access rules. Row level security on tables and document permissions on files must give the same answer. Sombra warns that if retrieval does not enforce the same rules across both types, the AI can surface content a user was never meant to see.
3. Scan for hidden sensitive data. StackAI notes that tables can hide personal data in free-text columns, and documents can hold regulated data in headers, signatures and attachments.
4. Clean the document layer. Remove duplicates, retire outdated versions and tag each file with an owner, a date and a source. A model cannot tell which policy is current unless the metadata says so.
5. Define shared keys. Agree on the identifiers that link documents to records before you index anything.
6. Test with real questions. Build a set of questions your users actually ask, with known answers. Run it after every change to data or prompts.
7. Plan upkeep. Documents and records go stale. Set a refresh schedule and an owner for each source.

For the wider program around this work, SotaTek's guide to digital transformation with AI shows where data readiness fits next to use case selection, integration and governance.

Structured vs Unstructured Data for AI: The Bottom Line

Structured data gives AI accuracy. Unstructured data gives it context. A forecast, a score or a total belongs with structured systems. A summary, a search or an inspection belongs with models built for language and images. The most valuable use cases need both, joined by shared keys and governed by the same access rules.

Start small. Pick one use case, list the data it needs from each side, fix the gaps in that data and test with real questions before you scale.

Ready to see what your data can support? Talk to SotaTek about a data readiness review and an AI architecture that puts both structured and unstructured data to work.

SotaTek Korea participated in the event to showcase its enterprise AI solutions and in-house products under the Made by SOTA portfolio. One of the highlights was SotaTek Korea's achievement in receiving the Excellence Award at the DMTS Global Startup IR Competition, adding another milestone to its participation.

This article looks back at DMTS 2026, SotaTek Korea's exhibition activities, the AI solutions presented, and its award-winning achievement.

1. DMTS 2026: Connecting Digital Technology with Business Opportunities

The Digital Media Tech Show (DMTS) is a specialized exhibition for digital media and technology, hosted by Goyang Special City and organized by KINTEX.

The 2026 edition was held over three days, from November 4 to 6, at Hall 2, KINTEX Exhibition Center 1.

Covering a broad range of technology fields, the exhibition featured developments in AI, data technology, XR, digital content, media platforms, displays, and digital marketing. It provided an opportunity for businesses to explore emerging technology trends and understand how digital solutions are being applied across industries.

Beyond showcasing new technologies, DMTS 2026 also created opportunities for technology providers and businesses to discuss practical applications, explore potential partnerships, and identify new business opportunities. Supporting programs included investment and business consultation sessions, industry conferences, and the Global Startup IR Competition.

DMTS 2026 at a Glance

2. SotaTek Korea Showcases Enterprise AI Solutions at Booth B25

SotaTek Korea at DMTS 2026 – Booth B25

At DMTS 2026, SotaTek Korea welcomed visitors at Booth B25, where it presented enterprise AI solutions and its in-house Made by SOTA product portfolio.

The exhibition focused on demonstrating how AI can be applied to real business operations and industrial environments. SotaTek Korea also engaged with business representatives to discuss potential AI adoption approaches based on their specific operational requirements and business needs.

Among the featured products were NoteX, Saydi, and SotaVision.

NoteX: AI-Powered Meeting and Work Management

NoteX is an AI-powered meeting management solution designed to help organizations record and organize meeting information more efficiently.

By applying AI to meeting documentation and information management, NoteX supports organizations looking to improve workplace productivity and streamline internal communication.

Saydi: Real-Time AI Translation

Saydi is a real-time AI translation solution that helps reduce language barriers and facilitate global communication.

It can support organizations operating in multilingual environments, particularly businesses working with international clients, partners, and teams.

SotaVision: AI Vision-Based Solutions

SotaVision is an AI vision-based solution that uses image and visual data to support applications across different industries.

Its capabilities are relevant to businesses exploring computer vision and AI applications in industrial environments, including manufacturing.

Through these product demonstrations and discussions, SotaTek Korea aimed to go beyond introducing AI technologies. The team explored how AI solutions could be adapted to different business environments and industry-specific requirements.

View Made by SOTA solutions

3. SotaTek Korea Wins Excellence Award at the DMTS Global Startup IR Competition

Another major highlight of SotaTek Korea's participation in DMTS 2026 was receiving the Excellence Award at the Global Startup IR Competition.

The competition provided participating companies with an opportunity to present their businesses through pitch materials and presentations. According to the competition guidelines, applicants were required to submit presentation materials in a free format, with a maximum length of 15 pages.

Investor Relations (IR) is the process through which a company communicates its business model, growth potential, technology, and business competitiveness to investors and other stakeholders. For startups and technology companies, IR activities can play an important role in presenting their business direction and exploring potential investment and partnership opportunities.

For SotaTek Korea, receiving the Excellence Award added a significant achievement to its participation in DMTS 2026. It marked an opportunity not only to introduce its AI solutions at the exhibition but also to gain recognition through the global startup IR program.

• SotaTek Korea receives the Excellence Award at the DMTS 2026 Global Startup IR Competition.

4. Supporting Enterprise Digital Transformation Through AI Solutions

As AI adoption continues to expand, businesses are moving beyond simply exploring new technologies. More organizations are looking for practical ways to apply AI to improve operational efficiency, optimize workflows, and achieve measurable business outcomes.

In manufacturing, for example, AI is increasingly being explored in areas such as production automation, quality inspection, equipment monitoring, and data analysis.

However, successful AI adoption requires more than selecting a technology. Businesses also need to consider integration with existing systems, data infrastructure, implementation costs, security, and ongoing maintenance.

SotaTek Korea supports these needs through its AI development and IT consulting capabilities, helping businesses identify technology solutions that align with their operational environments and business objectives.

Through its Made by SOTA portfolio, SotaTek also demonstrates practical applications of AI technology while providing customized development and digital transformation support based on individual business requirements.

Its participation in DMTS 2026, together with the Excellence Award at the Global Startup IR Competition, reflects SotaTek Korea's continued efforts to connect AI technology with practical business applications.

5. Looking Back at DMTS 2026: Building New Opportunities for AI Collaboration

The 2026 Digital Media Tech Show provided a platform for exploring how AI and digital technologies can create new opportunities across different industries.

During the event, SotaTek Korea introduced its enterprise AI solutions and Made by SOTA products, connected with business representatives, and received the Excellence Award at the Global Startup IR Competition.

Looking ahead, SotaTek Korea will continue leveraging its capabilities in AI, data, cloud, and software development to support digital transformation and business innovation for companies in South Korea.

For businesses considering AI adoption, choosing the right technology partner is an important step toward turning digital initiatives into practical business outcomes.

Looking to achieve greater business success with AI? Partner with SotaTek Korea to explore AI solutions and IT services tailored to your business needs.

👉 AI Solutions and IT Services: Contact SotaTek Korea

Frequently Asked Questions (FAQ)

Q1. When was the 2026 Digital Media Tech Show (DMTS 2026) held?

DMTS 2026 was held from November 4 to 6, 2026, at Hall 2, Exhibition Center 1, KINTEX, in Goyang, South Korea.

Q2. What technologies were featured at DMTS 2026?

The exhibition covered various digital technology fields, including AI, machine learning, data analytics, AI automation, XR, digital content, media technology, and digital marketing.

Q3. What solutions did SotaTek Korea showcase at DMTS 2026?

At Booth B25, SotaTek Korea presented its enterprise AI solutions and Made by SOTA products, including NoteX, Saydi, and SotaVision.

Q4. What award did SotaTek Korea receive at DMTS 2026?

SotaTek Korea received the Excellence Award at the 2026 DMTS Global Startup IR Competition.

Q5. Can businesses consult SotaTek Korea about AI solutions?

Yes. SotaTek Korea provides consultation on AI solutions and IT services based on individual business requirements and operational environments. Businesses can contact the team through the official SotaTek Korea website.

Held during General Secretary and State President To Lam’s official visit to Japan, the forum focused on co-creating technology and shaping future value chains. It brought together government representatives, organisations and businesses from Vietnam and Japan to advance economic cooperation through science, technology and innovation.

The event was organised by Vietnam’s Ministry of Finance, Ministry of Science and Technology, Ministry of Culture, Sports and Tourism, and the Vietnamese Embassy in Japan. Japanese co-organisers included the Ministry of Economy, Trade and Industry (METI), Ministry of Finance (MOF), Ministry of Education, Culture, Sports, Science and Technology (MEXT), and Japan External Trade Organization (JETRO).

Discussions focused on joint research, technology development and commercialisation, stronger links between businesses and academic institutions, and the development of skilled talent. These priorities aim to combine the strengths of both countries through cooperation programmes with clear objectives and practical implementation pathways.

The cooperation documents exchanged at the forum covered a range of sectors, including information technology, artificial intelligence (AI), semiconductors, renewable energy, green transition, healthcare, education, finance, aviation, agriculture and logistics. The signing activities provided a basis for businesses and organisations from both countries to translate shared priorities into cooperation initiatives.

SotaTek’s participation and exchange cooperation documents at the forum build on its ongoing efforts to expand partnerships in Japan. In March 2026, SotaTek Japan opened its Fukuoka office to strengthen support for clients in western Japan. The company is also a member of the Vietnam–Japan Digital Transformation Association (VADX Japan), connecting with the technology business communities of both countries.

With capabilities in software development, AI and systems integration, SotaTek continues to pursue partnerships that address practical business needs. Through its local presence and partner network in Japan, the company aims to support technology adoption and contribute to closer technology cooperation between Vietnam and Japan.

Early-stage companies need more than developers. They need a technology partner who understands the founder's vision, helps turn ideas into viable products, and moves quickly from concept to execution.

As the business grows, however, technology demands evolve. Products become more complex, engineering requirements expand, and companies need the capacity, expertise, and delivery structure to support their next stage of growth.

This is where CyberK and SotaTek bring their strengths together.

CyberK works closely with startups and founders, particularly across AI and Web3, helping them transform ideas into working products. From product discovery and MVP development to technical execution and ongoing product support, CyberK focuses on helping founders build, validate, and move their products forward.

SotaTek, an AI & Blockchain Innovation Partner, brings the engineering depth and delivery capabilities to support businesses as their technology needs grow. With extensive software engineering experience, technical consulting capabilities, and the ability to mobilize dedicated engineering teams, SotaTek helps companies expand their development capacity and take on more complex technology initiatives.

Together, the two companies aim to provide a more connected technology journey:

• BUILD – Turn ideas into products through discovery, product development, and MVP delivery.
• RUN – Continue improving, maintaining, and supporting products as they gain traction.
• SCALE – Expand engineering capacity and technical capabilities as business requirements become more demanding.

The goal is simple: help businesses move from an initial idea to a growing, evolving technology operation, with complementary capabilities supporting them along the way.

We are excited to bring this partnership to life and explore what we can build together.

One partnership. Complementary strengths. From the first build to the next stage of

AI access control and permission management determines who can use an AI application, which information it can retrieve, and what actions an AI agent can perform. These decisions become more complex when an assistant searches across enterprise repositories or uses a service account with broader access than the employee requesting the task.

A system that answers accurately can still expose a confidential contract or execute an unauthorized action if permissions are not enforced throughout the workflow. At SotaTek, we help enterprises develop AI applications and agents that connect with existing systems while accounting for identity, data access, and operational governance requirements.

In this guide, SotaTek will explain how to manage permissions across users, agents, retrieval pipelines, and connected tools, with practical guidance on delegated access, authorization testing, and revocation.

Key Takeaways

• AI access control and permission management requires decisions at the application, retrieval, and tool layers—not only at login.
• For user-delegated actions, enforce applicable user authority, the agent's permitted scope, and organizational policy together.
• Filter retrieved documents before their contents reach the model; recheck permissions when authorization information can be stale.
• Separate autonomous service authority from delegated user authority and give agents distinct, scoped identities.
• Bind approval to the exact action and arguments, then reauthorize before execution; a model-generated request is not proof of permission.
• Test revocation, cross-tenant access, stale caches, tool misuse, and approval replay as application-level security outcomes.

What Is AI Access Control and Permission Management?

AI access control and permission management applies identity, authorization, and governance controls to AI applications and the systems they use. Authentication identifies a user or workload. Authorization determines whether that identity may perform a specific action on a specific resource under the current conditions. Permission management maintains those grants throughout their lifecycle.

In an AI workflow, there can be several principals: an employee, an application, an agent, and a downstream service. Each must be represented accurately. If a service account can read a document, that does not automatically mean the requesting employee can read it. Similarly, a user authorized to view an invoice may not authorize an agent to change its payment details.

The AWS Agentic AI Lens distinguishes agents acting on a user's behalf from agents operating autonomously. AWS recommends separate agent and human identities, verified communication, scoped credentials, and regular permission reviews. For delegated tasks, user context should travel through the call chain without the agent taking possession of the user's credentials.

Delegated vs autonomous access

Do not assume every agent action always requires a currently active human user. For autonomous work, define a distinct service authorization and owner. For delegated work, the effective authority should be bounded by the user's current authorization, the agent's scope, the resource policy, and any constraints on the task.

Where AI Permission Risks Arise

AI access control and permission management must cover several boundaries as an assistant crosses them when it receives a question, retrieves information, calls a model, and optionally acts on the answer. A check at the front door does not automatically protect the downstream resources.

Prompt injection makes these boundaries more important because retrieved content or a user message may ask an agent to ignore instructions or call an unauthorized tool. A policy engine must decide whether a resource operation is permitted; the LLM can propose an action but cannot grant itself access.

The OWASP AI Agent Security Cheat Sheet recommends restricting tools, isolating memory and preventing privilege escalation across agent chains. Treat this as a set of checks at enforcement points: signing an agent message authenticates the sender but does not itself authorize the requested action.

Design an AI Access Control Architecture

An AI access control and permission management architecture separates identity verification, policy decisions, and enforcement. An authenticated request enters the application with a verified user or service identity. A policy decision point evaluates the principal, agent, action, resource, and context. Enforcement points at retrieval and tool gateways prevent unauthorized operations before content or side effects leave the boundary.

Define the policy inputs

Record at least the caller identity, tenant, agent identity, requested action, target resource, purpose or task, and relevant environmental constraints. For user-delegated access, propagate trusted user context through the chain. Claims supplied by a model or typed into a prompt are untrusted; they must never override authenticated identity.

The Microsoft guidance on agent access patterns distinguishes agent identity from user identity and explains delegated access through an on-behalf-of flow. The design implication is to preserve both identities in policy evaluation and logs: the person requesting the task and the agent or application executing it are different actors.

How Microsoft Entra separates agent identity from its blueprint

In Microsoft's model, an agent identity is a tenant-local service principal created from an agent identity blueprint. The blueprint carries shared application metadata and credentials used to acquire tokens for those agent identities; an individual agent identity has its own object ID but does not hold its own credentials. A sponsor can identify an accountable human user or group. Some integrations also require a separate agent user account; it is a distinct object linked to the agent identity.

For an interactive request, record the user as the subject and the agent as the actor where the platform exposes those claims. For an autonomous task, assess the agent identity and its app-only permissions without inventing a human user context. Blueprint-wide changes can help govern a family of agents, but each deployment still needs resource-specific permissions, ownership, and a tested disablement path.

Token exchange is useful when a downstream service needs a different audience or narrower authority. IETF RFC 8693 distinguishes delegation from impersonation; a token exchange alone does not prove that the downstream policy is correct. Validate issuer, audience, expiry, actor and subject claims, and resource permissions at each hop.

Compare RBAC, ABAC, and relationship-based controls

These models solve different policy questions and can be combined. The choice should reflect whether access depends primarily on job role, resource attributes, or relationships between people and resources.

A practical policy may combine a role granting document-search capability with a resource relationship granting access to one folder, plus a tenant boundary and task-specific agent scope. An explicit deny or missing required attribute should not be silently converted into access.

For a concrete policy model, NIST SP 800-162 defines attribute-based decisions over the subject, object, operation and sometimes environment. In a RAG assistant, those attributes can represent a user’s department, document classification, requested read operation and tenant; each attribute still needs a trustworthy source and freshness policy.

Implement Permission-Aware RAG

RAG must protect the contents selected for the model, not just the final answer. If an unauthorized chunk reaches the prompt, an output filter may fail to prevent disclosure. Enforce permissions at ingestion, indexing, query, and response stages, with ownership for stale or missing authorization data.

Ingest permissions with the content

Record a stable source document ID, tenant ID, classification, and a reference to the authoritative access policy or synchronized permissions. Link every chunk and derivative representation to its source. A document may inherit permissions from a folder, change ownership, or be deleted after indexing; the pipeline needs a way to update or invalidate derived chunks.

Google Cloud's guidance on data-store access notes that, for supported third-party connectors enforcing end-user document permissions, individual document access remains governed by synchronized source ACLs. A grant to the data store does not itself override those source ACLs. For a custom RAG system, verify the connector's actual sync behavior, supported permission types, and revocation delay rather than assuming all sources behave the same way.

How Google Cloud separates ingestion from serving

The Google Cloud RAG reference architecture separates the ingestion subsystem from the serving subsystem. Ingestion moves source data to Cloud Storage, uses Pub/Sub events and Cloud Run functions to generate metadata, and imports documents into a managed datastore for parsing, chunking and embeddings. At serving time a Cloud Run frontend forwards the question to a backend, which constructs query filters and starts the search-and-generation workflow.

The security column above is our implementation guidance, not a claim that the reference architecture automatically enforces every document ACL. Check the actual connector, datastore configuration, identity propagation and filter semantics. Project or datastore IAM controls who can use cloud resources; it does not by itself establish that a given end user may read every underlying document.

Enforce permissions before content reaches the model

The retrieval service should receive identity and tenant context from trusted middleware, apply permitted-resource constraints, and send only authorized chunks to the model. Where the index cannot enforce the full policy, perform an authoritative check before exposing each candidate's content or metadata. Design for timing, cache, and metadata leakage as well as raw document text.

The following Python example models an authorization decision in memory. It is deliberately small and does not validate tokens, call a policy engine, enforce source ACLs, or secure a vector database. Production code must obtain all policy inputs from trusted systems and enforce decisions at the retrieval boundary.

from dataclasses import dataclass

@dataclass(frozen=True)
class AccessRequest:
    user_tenant: str
    document_tenant: str
    user_can_read: bool
    agent_can_retrieve: bool

def allow_retrieval(request: AccessRequest) -> bool:
    return bool(request.user_tenant) and all((
        request.user_tenant == request.document_tenant,
        request.user_can_read,
        request.agent_can_retrieve,
    ))

assert allow_retrieval(AccessRequest('a', 'a', True, True))
assert not allow_retrieval(AccessRequest('a', 'b', True, True))
assert not allow_retrieval(AccessRequest('a', 'a', False, True))
assert not allow_retrieval(AccessRequest('a', 'a', True, False))

This example illustrates an intersection of grants for a delegated request. Real policies must also handle group membership, inherited permissions, explicit denies, resource classification, expiration, and policy-service failure. Do not accept Boolean access claims from the client or model.

Handle revocation and cached answers

A permission change must reach every relevant layer: source ACL, authorization service, index metadata, retrieval cache, generated-answer cache, and session state. Define an acceptable revocation propagation window and test it against your risk requirements. Where immediate checks are required, reauthorize against an authoritative service rather than relying solely on delayed index updates.

Cached answers deserve the same scrutiny as retrieved documents. An answer generated for an authorized user may contain information that another user—or the same user after access is revoked—cannot receive. Partitioning by user or tenant helps, but does not remove the need to account for later permission changes.

Control Agent Tools and Delegated Actions

AI access control and permission management changes when an agent can take action. A model may request an API call because a user asked for it, a document instructed it, or an output was misinterpreted. The tool gateway must independently validate who is requesting what, against which resource, under which grant.

The AWS tool authorization guidance recommends policy enforcement before every tool invocation, propagation of agent and user identity, and human checkpoints for high-risk changes. The important distinction is between granting an agent the ability to call a tool and authorizing a particular operation on a specific resource.

How AWS protects identities, tools and agent sessions

The AWS Security Reference Architecture for generative AI agents identifies distinct controls for runtime isolation, agent credentials, tool connectivity and observability. Its design illustrates why a guardrail that screens prompts is only one layer: the system also needs a policy decision for the requested resource and action.

For example, a support assistant can read an order through one allowed tool while a refund requires a separate action policy and, where appropriate, approval. The gateway should verify the actor and target, check the requested amount and order against the current policy, then use credentials limited to that API. An approval and an audit trace are supporting controls; neither automatically grants access at the payment service.

Gate the exact action

For a payment-change request, the gateway should validate the user, agent, tenant, supplier, target account, amount where relevant, and current policy before execution. A human approval should bind those exact arguments, the approver, the requester, an expiration, and a unique operation identifier. Recheck authorization and resource state at execution time; consume the approval once and reject altered or replayed requests.

Use short-lived credentials with narrow audiences and scopes. Keep secrets outside model prompts and avoid broad shared accounts. An agent that only drafts messages does not need permission to send them; an agent that updates one support queue does not need tenant-wide write access.

Prevent cross-agent privilege escalation

In a multi-agent workflow, agent A calling agent B does not automatically transfer A's authority or the user's full authority. Authenticate both services, propagate verified context, and evaluate the requested delegation against the target agent's policy. Record the chain of actors so reviewers can establish who initiated the task and which agent performed each action.

Test and Monitor AI Permissions

A successful functional answer does not demonstrate correct authorization. Test the complete path using synthetic identities, tenants, documents, and tools. Assert on what the system retrieved and executed, not only on what the final response says.

The Open Policy Agent testing guide demonstrates policy tests for both allowed and denied operations. Apply that principle to AI workflows by testing the policy in isolation and then testing the integrated retrieval and tool paths. A passing policy unit test is insufficient if a downstream tool can be called without consulting it.

Monitor decisions and investigate drift

Log the user or initiating service, agent identity, tenant, action, resource identifier, decision, policy version, correlation ID, and approval reference where applicable. Avoid putting full sensitive documents, secrets, or access tokens into logs. Protect log integrity, control access, define retention, and connect alerts to incident response.

Review changes in effective access whenever agents gain new tools, new datasets are indexed, roles change, or a workflow moves from drafting to execution. Track unused grants, denied access patterns, exceptions, and time to revoke. Do not grant broad permissions automatically merely to silence an access-denied error.

Build a Permission Management Roadmap

An AI access control and permission management roadmap connects design decisions to evidence the team can review before expanding autonomy. The appropriate sequence and approval authority depend on the workload's impact and the organization's security model.

Start with a bounded read-only knowledge assistant. Test source permissions, tenant isolation, and revocation before adding tools one at a time. For deployment choices and consistent governance across environments, read our guide to hybrid cloud.

How SotaTek Support AI Access Control

Through our AI development services, we help teams assess use cases, prepare data, build AI applications, integrate existing systems, and plan deployment and operational support. We agree on the security scope, responsibilities, and acceptance criteria with your team for each engagement.

For AI access control and permission management in a knowledge assistant, we can help map users, source systems, access rules, retrieval flows, and exception handling. For an agentic workflow, we can work with your security and engineering teams to define tool boundaries, approval points, application integration, and test cases. The final identity architecture and policy enforcement remain aligned with your organization's own controls and operating environment.

Choosing an implementation partner also requires evaluating experience, delivery processes, and the ability to work with existing teams. Explore our guide to choosing an AI development partner for a broader selection framework.

Case Study: Managing AI Access and Governance with SotaAgents

As enterprises introduce AI across departments, managing access becomes more complex. Different teams may need different knowledge sources, AI models, and business tools, while administrators need visibility into how these resources are used. Without centralized controls, fragmented AI adoption can make it difficult to manage permissions and interactions with sensitive information.

To address these challenges, we developed SotaAgents, an enterprise AI platform that brings knowledge retrieval, AI agents, workflow orchestration, and governance into a unified environment. The platform allows organizations to configure access at the organization and workspace levels through:

• Role-based access control (RBAC) and single sign-on (SSO): Manage user access according to organizational roles and authentication requirements.
• Workspace-level knowledge isolation: Organize knowledge and data within separate workspaces so teams can access information relevant to their responsibilities.
• Model and tool permissions: Configure which AI models, connected tools, and actions are available within the organization or a workspace.
• Usage monitoring and audit logs: Give administrators visibility into AI usage and activities to support governance and review.
• AI guardrails: Apply configurable input and output controls alongside access policies.

SotaAgents has been applied to enterprise knowledge retrieval, AI governance, document processing, and workflow automation. For organizations planning AI access control and permission management, the platform illustrates how user permissions, knowledge access, and agent capabilities can be managed within a broader enterprise AI environment.

Conclusion

AI access control and permission management requires consistent decisions across the full AI workflow—from the user’s request to document retrieval and downstream tool execution. Separate user and agent identities, apply permissions before information reaches the model, and test whether access changes are enforced across indexes, caches, and connected services.

At SotaTek, we help enterprises build AI applications and agents around their existing systems and governance requirements. From mapping data access and designing permission-aware retrieval to integrating tools and defining security tests, we work with your teams to establish controls suited to the use case. Contact us to discuss your AI access and deployment requirements.

At SotaTek, we help organizations develop and integrate AI applications around their existing data, business systems, and deployment requirements. This guide explains how to match infrastructure to the workload, choose where components should run, and establish the controls needed for production.

Key Takeaways

• Begin with the business workflow, data boundaries, and service objectives before selecting hardware or a cloud platform.
• Plan interactive inference, retrieval, batch processing, and model development as different workloads with different resource needs.
• Connect infrastructure layers through managed identities, documented interfaces, observability, and clear ownership.
• Evaluate cloud, private, hybrid, and edge deployment against total cost, data location, operating capability, and recovery requirements.
• Measure usable business outcomes alongside latency, availability, security, and resource consumption.

What Is AI Infrastructure for Enterprise?

AI infrastructure for enterprise is the foundation used to build, deploy, operate, and improve AI applications. It includes compute and accelerators, data pipelines, storage, networking, model-serving software, application integrations, and the people and processes that manage them.

An employee asking a knowledge assistant a question triggers more than a model call. The application authenticates the user, retrieves permitted documents, sends selected context to a model, returns an answer, and records operational information. If any component is unavailable, slow, or incorrectly configured, the user experience and the organization's risk can change. Understanding this full path is the first step in designing AI infrastructure for enterprise workflows.

Infrastructure for AI versus AI for infrastructure

Infrastructure for AI provides resources and services that AI applications consume. AI for infrastructure uses AI to help operate IT environments. For example, to summarize incidents or support root-cause analysis. The two can work together, but this guide focuses on the first: designing the foundation that enterprise AI workloads need.

An enterprise may need a shared platform for several use cases while keeping their data, quotas, and deployment policies separate. Our guide to enterprise AI architecture covers how these shared layers connect to applications and governance.

Key Layers of AI Infrastructure

The layers of AI infrastructure for enterprise are interdependent. More GPU capacity, for example, will not resolve a retrieval bottleneck or an unavailable identity provider. Each layer needs a defined purpose, interface, owner, and recovery plan.

Start with a service contract

For each use case, document its users, task, source systems, permitted actions, sensitivity, availability target, and acceptable response time. Define a named owner for the application, the data, the model endpoint, and incident response. This contract gives platform teams a basis for choosing capacity and makes trade-offs in AI infrastructure for enterprise workloads visible before procurement.

For a discussion of deployment decisions across existing environments, see our guides to hybrid cloud and public, private, and hybrid cloud models.

Match Infrastructure to AI Workloads

A single platform may support several workloads, but each puts pressure on a different part of the stack. Classifying them helps avoid sizing AI infrastructure for enterprise around the needs of one pilot.

Estimate model memory before purchasing capacity

NVIDIA's GPU memory guidance breaks inference memory into model weights, the key-value (KV) cache, activations, communication buffers, and runtime overhead. Its weight estimate is parameter count multiplied by bytes per parameter, divided by the tensor-parallel degree when applicable.

For example, an 8-billion-parameter model in BF16 has approximately 16 GB of weights: 8 billion parameters multiplied by two bytes. That is a starting estimate, not the memory required for the complete service. Context length, concurrent sessions, KV cache, runtime allocations, and model architecture add to the requirement. Validate the actual model, precision, and serving engine on the intended hardware before finalizing AI infrastructure for enterprise use.

Case study: Capacity separates real-time and offline work

In a 2025 Microsoft customer story, enterprise search provider Capacity describes using Phi small language models for both query processing and offline content enrichment. Its stack includes Azure Kubernetes Service, Azure AI Search, PostgreSQL, and services for language and video processing. Separating preprocessing from query-time work helps the company prepare searchable metadata ahead of a user request.

Microsoft reports that a summarization task decreased from 12–14 seconds to 4–5 seconds in the described implementation. The figures are vendor-reported results for that workflow, not a universal model or infrastructure benchmark. The practical lesson is to move suitable enrichment work out of the interactive path, then measure whether quality and latency remain acceptable.

Choose a Deployment Model

AI infrastructure for enterprise can combine managed model APIs, rented accelerators, private environments, and edge devices. The placement decision should follow the workload's data, demand, integration, and operating constraints.

Compare total cost, not only accelerator price

Include compute, model or API usage, storage, networking, software, monitoring, support, staffing, redundancy, and equipment lifecycle costs. For private infrastructure, account for idle capacity and procurement lead time. For cloud services, model sustained and peak usage, data-transfer costs, quota increases, and provider dependencies.

Treat the calculation as a scenario analysis, not a fixed rule. A model used occasionally by a small team has a different cost profile from a high-volume service with stable demand and strict data-location requirements. When planning AI infrastructure for enterprise use, revisit placement as utilization, model size, or contract terms change.

Design a Production AI Infrastructure Architecture

A production architecture should show where requests enter, how data is retrieved, which model handles each task, and where authorization is enforced. In AI infrastructure for enterprise knowledge assistants, the path might look like this:

1. The application authenticates the user and passes verified identity and tenant context to trusted services.

2. A retrieval service searches an index using the user's permitted scope and returns authorized content.

3. An application orchestrator sends the selected context to an approved model through a gateway or service endpoint.

4. The response is validated and returned; proposed tool actions pass through a separate authorization decision.

5. Monitoring records latency, failures, policy decisions, and cost with appropriate controls on sensitive data.

How Microsoft explains the model gateway

Microsoft's gateway architecture places a gateway between applications and model endpoints. Its conceptual design groups federated authentication, rate limiting, routing, monitoring, caching, load balancing, and queues. It can route traffic to model deployments in different locations, including on-premises environments.

Microsoft also warns that a gateway can become a single point of failure and may affect streaming or stateful interactions. Design for availability, test long-lived connections, and include the gateway in failure-mode analysis. When a gateway supports AI infrastructure for enterprise applications, it does not automatically enforce source-document permissions or authorize downstream business actions.

Connect models across environments

In its networking reference for AI inference, Google Cloud describes a unified frontend that routes requests by model name to backends hosted in different environments. Its example uses a private endpoint, an internal load balancer, API management, and configurable safety checks. The design also notes that incompatible backend APIs require translation, which is outside the reference implementation.

For a hybrid implementation, map each request's route, identity, encryption, approved destination, and network cost. A single interface can simplify consumption, but teams still need to understand which provider processes each request and what happens when a backend fails. These decisions connect network design with AI infrastructure for enterprise integration. Our guide to AI integration with ERP and CRM provides additional context for connected workflows.

Secure and Govern Enterprise AI Infrastructure

Security for AI infrastructure for enterprise spans users, data, models, tools, and operations. A network boundary helps restrict connectivity, while application and resource-level authorization determine whether a particular request is allowed.

Control access throughout the workflow

Use separate identities for users, applications, and agents; grant only the permissions needed for the task. Protect credentials outside prompts, isolate tenants or workspaces as appropriate, and enforce current document access before retrieved content reaches the model. For actions such as editing records or sending data externally, validate the requested operation and require approval when the impact warrants it.

Model weights, container images, dependencies, and deployment configurations also require ownership and change control. For AI infrastructure for enterprise workloads, assess external provider retention and processing terms, and decide which logs may contain prompts or business data. Our enterprise AI governance guide explores the related organizational responsibilities.

Design for recovery and evidence

Test model endpoint outages, expired credentials, source-system failure, access revocation, and stale indexes. Define how the system behaves when its authorization service is unavailable and how teams restore the model version, configuration, index, and application together.

Instrument the request path with a correlation ID and record the responsible application, model version, decision, latency, error, and estimated cost where available. Avoid capturing sensitive prompts or full documents by default. Agree on retention, access, and incident escalation before AI infrastructure for enterprise users goes live.

Plan Capacity, Cost, and Reliability

Capacity planning for AI infrastructure for enterprise begins with a representative workload. Capture request volume and peaks, input and output length, concurrency, response-time objectives, data freshness, and the time required for a new replica to become ready. Test a realistic mix rather than a single short prompt.

Worked example: estimate serving replicas

Suppose a representative test shows that one replica can sustain two requests per second while meeting the agreed latency and quality targets. Forecast peak arrival is eight requests per second, and the team chooses a planning target of 70% of that measured rate per replica to leave headroom.

This is illustrative arithmetic, not a production sizing recommendation. Requests with longer contexts or outputs may need more capacity; queueing, burstiness, model warm-up, quotas, network delays, and GPU availability also affect the result. Validate the estimate with load tests, failure tests, and the actual service-level objective before committing infrastructure.

Measure cost per useful outcome

Track time to first token, end-to-end latency, queue time, error rate, retrieval quality, and availability alongside infrastructure and model costs. Allocate shared costs consistently and include failed attempts, human review, data transfer, and storage when evaluating AI infrastructure for enterprise workflows.

For example, a cheaper model response can increase total cost if poor extraction leads to repeated calls or manual correction. Compare cost per request with cost per accepted task and task quality; use the result to decide whether a routing, model, or infrastructure change is worthwhile.

Case study: Observe.AI scales managed inference

In an AWS customer story, Observe.AI describes using Amazon Bedrock and Amazon Nova Lite for high-volume contact-center AI workloads. The managed model path was integrated into existing services to support both batch and latency-sensitive use cases while reducing part of the model-management burden.

AWS reports approximately 90,000 requests and 100 million tokens per minute across regions, together with 10–15 times growth in model consumption over roughly one year. These figures describe the reported deployment and do not establish the performance or cost of another system. The example illustrates a managed-inference choice at scale; it does not imply that every workload should use the same model or provider.

How SotaTek Build AI Infrastructure for Enterprise

At SotaTek, we help organizations connect AI applications with the data, infrastructure, and business systems they need. Our work on AI infrastructure for enterprise use cases can include assessing workloads, designing architecture, developing AI applications and agents, integrating enterprise systems, and planning deployment and operations with the client's teams.

Case study: Deploying Sotabox on GreenNode

Overview and challenge: As we prepared Sotabox.ai for cloud deployment, we needed to establish an operational environment within one month while supporting the platform’s rollout to end users. Our team also wanted to reduce infrastructure management effort through platform-as-a-service (PaaS) components and maintain access to technical support during the initial deployment.

Deployment and solution: Working with GreenNode, formerly VNG Cloud, we configured vServer compute, vStorage, a load balancer, managed Redis and PostgreSQL databases, and Kafka. GreenNode provided technical support during setup, integration, and testing, including work involving vMonitor and VKS. Once the core environment was operating, we extended Sotabox features to end users. The teams also tested Dataiku integration on the existing infrastructure as a separate initiative.

The following example shows how these components could support a document-based AI application:

1. Document submission: A user uploads a document through an application endpoint behind a load balancer.
2. File storage: The application service stores the document in object storage.
3. Task creation: The application publishes a processing task to a queue.
4. Document processing: A worker receives and processes the queued task.
5. Supporting services: A database stores application metadata, while an optional cache can speed up access to frequently requested information.
6. Monitoring: A monitoring service tracks system health and detects failures.

Results: GreenNode reports that the deployment ran from February 15 to March 15, 2025, and that DevOps costs decreased by 30%. The source does not state the baseline, cost components, or measurement method for that percentage. It also reports that managed services reduced operational effort; these figures do not independently establish inference performance, security effectiveness, or a guarantee for other implementations.

Infrastructure takeaway: A phased rollout can establish core compute, storage, networking, and managed services before expanding access to users. For a comparable project, teams should validate capacity, data access, observability, and recovery requirements against the actual workload before selecting the final architecture.

From assessment to operation

We start with a bounded use case and its data and integration requirements. The next steps are to select a deployment approach, build the required data and model path, define access and operating controls, and validate performance and quality using representative conditions. Once the workflow meets its agreed criteria, teams can expand AI infrastructure for enterprise applications and shared services in stages.

Our AI development services support this process. For related implementation decisions, explore our guides on:

• AI Agent Development Process: 8 Steps From Use Case to Production
• Top 10 AI Development Partners in Vietnam for 2026

Conclusion

AI infrastructure for enterprise becomes effective when compute, data, model serving, integration, security, and operations are designed around measurable business workloads. Start with a clear service objective, test the complete request path, and make ownership, cost, and recovery part of the architecture from the beginning.

At SotaTek, we help enterprises develop and integrate AI applications with a production path suited to their environments. Contact us to discuss your use case, infrastructure constraints, and implementation priorities.

AI data privacy and protection means controlling what information an AI system collects, where it moves, who can use it, how long it persists, and what can be inferred or disclosed. The practical goal is to deliver the task with the least sensitive data and the smallest necessary access at every step.

Key Takeaways

• Map data across training, prompts, retrieval, outputs, logs, vendors and backups before choosing controls.
• Treat retrieval permissions as an authorization problem: filter before the model receives documents, and re-check access when permissions change.
• Redaction, encryption and differential privacy solve different problems. None makes every AI workflow private by itself.
• Document vendor retention, model-training use, subprocessors, location and deletion terms; test what actually happens.
• Measure privacy with permission-denial tests, deletion completion and sensitive-data detection quality—not a single compliance label.

What Is AI Data Privacy and Protection?

Security protects information against unauthorized access, alteration and loss. Privacy asks whether the organization should process the information at all, for which purpose, under whose authority, and with what limits. Strong access controls cannot justify collecting unnecessary medical records; a privacy notice cannot prevent a misconfigured vector database from exposing them.

A useful starting point is a data-flow inventory: identify the data subject and business purpose, classify each field, record every processor and destination, and assign an owner and retention rule to every copy. Include embeddings, caches, evaluation datasets and observability systems—not just the original database.

For example, a support assistant may need a customer’s open ticket and product plan to draft a response. It usually does not need a full payment history, an identity document or unrelated internal notes. Define the task and approved fields first, then document who can see the result. This simple decision narrows both the exposure and the work required to manage copies later.

Membership inference can reveal whether someone was in a training set, while model inversion can infer information about individuals. In its AI security and data minimisation guidance, the ICO also notes that pseudonymisation reduces risk but does not automatically remove data-protection obligations. Classify derived artifacts and restrict access according to their sensitivity.

A privacy impact assessment should document the purpose, affected people, data categories, recipients, risks, controls and owners. Consult privacy counsel on when it is required, and revisit it after material changes to the use case, data sources or provider.

Where AI Data Privacy Risks Arise

Map exposure across the lifecycle

AI data privacy and protection failures rarely fit into one box. Each stage creates different copies, recipients and failure modes; assign an owner and a concrete control to each boundary.

Watch the less obvious copies

Embeddings are numerical representations of content, not a reliable anonymization guarantee. A retrieval index can carry sensitive metadata and may expose information through access, reconstruction or association. Treat embeddings and their metadata as sensitive according to the source and threat model.

Training and fine-tuning create a different lifecycle problem from ordinary retrieval. A document removed from a search index can stop appearing in future retrieval, but a model trained on that document may retain an influence that is difficult to isolate. Keep records of training dataset versions and their provenance, and agree in advance how deletion requests, retraining and provider-held copies will be handled.

In OWASP guidance on prompt injection, OWASP distinguishes direct attacks in user prompts from indirect attacks embedded in external content, such as websites and files. Either can influence an assistant’s output or cause it to misuse connected functions. Separate untrusted content from instructions, restrict tool privileges and enforce authorization in application code; prompt wording alone is not a security boundary.

Sensitive information can also reach an answer through training data or the application context. OWASP’s sensitive information disclosure guidance highlights personal records, credentials and confidential business information as potential exposures, and recommends measures such as data sanitization. Check what enters the context and what leaves it: output filters and prompt restrictions can fail, especially when an attacker manipulates instructions.

Build a Privacy-First AI Architecture

Control the data before it reaches the model

A defensible enterprise flow is: authenticated request → policy decision → minimize or redact → retrieve only authorized content → model inference through an approved endpoint → output checks → controlled audit record. Each arrow is a trust boundary worth documenting. If a request cannot be authorized, fail closed and return no sensitive content.

Use a sensitive-data classifier suited to the language, document type and error tolerance. Google Cloud’s classification and de-identification examples illustrate how detection can return the type, location and likelihood of a finding, then apply transformations such as redaction or masking. Detection can miss identifiers or flag harmless content, so test false negatives on representative data and avoid logging the values found.

Create separate routes for public, internal, confidential and restricted information. A classification decision can permit an approved hosted model, require redaction and a private endpoint, or stop the request pending review. Include structured fields, attachments and extracted text in the same policy; otherwise a clean prompt can still carry sensitive content in a PDF. Treat classifications as organizational policy labels, not universal legal categories.

Enforce access before retrieval

For retrieval-augmented generation (RAG), the retrieval service must enforce the requesting user’s tenant and document permissions before chunks enter the prompt. Metadata filters are useful only when the retrieval system enforces them server-side and the metadata is trustworthy. Refresh permissions on change, invalidate caches and verify the final document authorization before prompt assembly.

This simplified example shows the rule against an in-memory list; a production index must enforce equivalent predicates at the trusted query layer and obtain identity and permissions from a verified identity provider.

def permitted_chunks(user, chunks):

   if not user.get("authenticated"):

       return []

   return [c for c in chunks

           if c["tenant_id"] == user["tenant_id"]

           and c["document_id"] in user["allowed_docs"]]

user = {"authenticated": True, "tenant_id": "acme",

       "allowed_docs": {"policy-1"}}

chunks = [

   {"tenant_id": "acme", "document_id": "policy-1", "text": "..."},

   {"tenant_id": "other", "document_id": "policy-1", "text": "..."},

]

assert len(permitted_chunks(user, chunks)) == 1

Do not take tenant IDs or allowed document IDs directly from a browser or an LLM. This example does not cover group expansion, revocation propagation, authorization timing, audit logging or index-level enforcement. Test those separately, including changes made after a document is indexed.

Permissions also change over time. If an employee loses access to a source document, invalidate cached results and propagate the change to the index within a defined window. Until synchronization completes, a current authorization check against the source or a policy service can prevent a stale chunk from reaching the model. Test revocation, group changes and document moves across every retrieval path, including administrative and batch jobs.

AI Data Privacy and Protection: Choosing the Right Privacy Controls

Compare methods by the risk they reduce

Choose controls based on the data flow and attacker, not the most impressive technique. The following methods are complementary and have material limits.

Select a control for each disclosure path rather than applying one blanket treatment to all records. For example, encryption protects a stored index and its network traffic, while authorization determines which decrypted records a user can retrieve. Masking can reduce the content sent to a provider, but it may also remove context needed for an accurate answer. Measure that trade-off on representative tasks before making redaction the default.

A differential privacy guarantee applies to a defined mechanism and protected unit. In Nits guidelines on evaluating differential privacy, NIST treats the guarantee as a combination of mathematical parameters and implementation choices, and identifies practical hazards that can undermine it. Define the privacy budget, account for repeated releases and evaluate utility loss; arbitrary noise alone does not establish differential privacy.

Make deployment and vendor decisions explicit

A hosted API can be suitable for sensitive use cases when contractual and technical controls match the data classification. A self-hosted model can reduce certain transfers, but shifts infrastructure and security responsibilities to your team. A hybrid approach can route restricted data locally and less sensitive requests to an approved provider; account for network paths, failover and observability in either case.

In our hybrid cloud guide, we examine how private, public and on-premises environments can share workloads: sensitive data can remain in a controlled environment while another workload uses public-cloud capacity. For AI, map both data storage and inference paths before choosing the split. A hybrid architecture still needs explicit residency, access and governance controls.

Before procurement, obtain written answers on training reuse, abuse-monitoring logs, retention periods, deletion exceptions, data location, subprocessors, encryption, incident notification and audit evidence. Confirm the exact product, region, contract and configuration: vendor terms can vary. Review cross-border transfer obligations with counsel for the actual jurisdictions involved.

A vendor assessment should distinguish model improvement from service operations. A promise not to train on customer prompts does not by itself answer whether logs, backups or support records are retained. Ask for the exact retention setting, exceptions, subprocessor list and deletion process for the contracted service. Verify that configuration in the deployment environment and revisit it when features, regions or contracts change.

Implement and Test AI Data Privacy and Protection

Design deletion across all copies

A deletion request is a workflow, not a DELETE statement. Maintain lineage from source record to chunks, embeddings, caches, application logs, evaluation sets and vendor-held copies. Disable retrieval first, remove active copies, record downstream requests and verify completion against each system’s policy. Backups and legal holds may require documented exceptions and expiry handling. Fine-tuned models are harder: removing a source record does not automatically remove its influence from model weights; retraining or another validated approach may be necessary.

Whether an AI model can be considered anonymous depends on the circumstances. EDPB Opinion 28/2024 considers the likelihood of identifying people or extracting their personal data from a model, as well as legitimate interest and the implications of unlawfully processed training data. Do not assume that weights or embeddings are anonymous simply because they are not raw records.

For a deletion request, store an internal record identifier and an inventory of derived assets; avoid putting the personal data itself into the deletion ticket unless needed. A coordinator can mark matching chunks unavailable, queue removal from each index and cache, request deletion from vendors where applicable, and record acknowledgments. Define what happens when a system is offline and how exceptions, legal holds and backup expiry are recorded. The case is complete only when the required systems report their outcome.

Not every record should be deleted immediately. Retention requirements, disputes or legal holds may affect the timing and method, so the workflow needs an exception state with an owner and review date. Separate access restriction from physical deletion and communicate the applicable status to the requester through established privacy procedures. For model weights, document whether retraining or another validated method is feasible instead of promising a technical capability the system does not have.

Test the boundaries with representative cases

Use synthetic records with known markers to test cross-tenant access, retrieval after revocation, attempts to override instructions in documents, unauthorized tool calls, sensitive output and deletion propagation. Test the negative path as carefully as the happy path. This minimal test captures one isolation property of the earlier example:

def test_cross_tenant_is_denied():

   user = {"authenticated": True, "tenant_id": "a",

           "allowed_docs": {"doc-1"}}

   other = {"tenant_id": "b", "document_id": "doc-1",

            "text": "synthetic marker"}

   assert permitted_chunks(user, [other]) == []

test_cross_tenant_is_denied()

This unit test is necessary but insufficient: run integration tests against the real identity service, retrieval engine, cache and deployed configuration. Track unauthorized retrieval attempts, the share of deletion tasks completed within policy, and detection false-negative rates on a representative labeled set. Define denominators, thresholds and ownership before launch; investigate regressions after every material model, prompt or retrieval change.

Build the evaluation set around failure modes that matter to the organization: a staff member requesting another team’s record, a retrieved page containing malicious instructions, an identifier split across lines and a deleted document still present in a cache. Use synthetic markers wherever possible. Record expected behavior, source permissions, model and application versions, and test results so that the same cases can be rerun after a change.

Assign owners and review gates

The product owner defines purpose and acceptable use; the data owner classifies sources and approves access; security owns threat modeling and technical validation; privacy and legal assess obligations; engineering implements and operates controls. A release gate should require a documented data-flow diagram, approved vendor terms, authorization tests, retention settings and an incident response owner.

NIST’s Generative AI Profile applies AI risk management to generative AI. Its framework organizes work around governance, mapping the system and its context, measuring risks and managing them over time. Use those functions to assign owners, evaluate a specific deployment and track residual risks; the framework is not a product certification.

Operational measures must make missed failures visible. For example, report the number of unauthorized retrievals blocked divided by the number of attempted unauthorized retrievals in a defined test suite, and separately track any unauthorized content that reached the model. A high detection percentage is misleading if the test set omits important languages, document formats or access scenarios. Review the denominator and ownership with security and privacy teams before relying on the metric.

Protect AI Data Privacy with SotaTek

A privacy-conscious AI implementation needs the right decisions at the data, model and deployment layers. SotaTek’s AI development services span AI readiness assessment, data preparation, model development, application development, integration and ongoing support. For teams working with sensitive information, these services provide a practical starting point for turning privacy requirements into an implementable AI project.

• AI readiness assessment and data preparation: SotaTek assesses an organization’s data, technology, processes, governance and team capabilities, then prioritizes use cases and develops a roadmap. Its data preparation work includes cleaning, labeling and structuring data for AI. In a privacy-sensitive project, use these stages to identify sensitive sources, define the intended processing purpose and agree which data should be excluded or transformed before model development.
• Model design and AI application development: SotaTek designs, trains and fine-tunes machine learning models and develops applications to meet business requirements. Its capabilities also include generative AI solutions, AI copilots and RAG integration. For a knowledge assistant, the project scope should specify how source permissions are enforced, what information reaches the model and how prompts and outputs are handled.
• Integration, deployment and ongoing support: SotaTek describes integrating AI models into existing systems and deploying them in cloud or on-premises environments, alongside monitoring, retraining and performance tuning. Its LLMOps capabilities include model deployment, testing, monitoring and RAG integration. For privacy, agree the deployment boundaries, logging policy, retention settings and responsibilities for testing and responding to incidents before launch.

In our guide to AI automation and RPA, we compare RPA’s predefined rules with AI automation’s ability to classify and interpret variable inputs. A team might use AI to extract information from an unstructured invoice, then use RPA to enter approved fields into a business system. Define the handoff and human review rules: limiting model access to the interpretation step can also reduce unnecessary data exposure.

The appropriate combination of these services depends on the use case, existing infrastructure and applicable obligations. Define the architecture, data-handling controls and acceptance tests in the project scope.

Conclusion

The strongest AI privacy design starts with a specific task and follows every piece of data it touches. Minimize inputs, enforce retrieval permissions outside the model, protect operational copies and validate deletion across systems. Choose deployment and vendor terms that support those controls, then test how they work together. Ready to build an AI solution with privacy requirements in mind? Contact us to discuss your use case, data boundaries and implementation priorities.

Ha Tang (Hạ Tầng in Vietnamese) puts that work in one place, with AI doing the repetitive part. It is built by Sota Labs, the products unit of SotaTek, and it is the platform under SotaTek's own products, including Hocdi.ai and tatca.ai. This article introduces Ha Tang, its main modules, who it is for and how to get started.

1. What Is Ha Tang?

Ha Tang is a business platform that joins customer support, sales, payments and invoicing into one flow. A customer writes on any channel, the AI assistant answers or a person takes over, the order is drafted in the chat, a VietQR payment is matched to it automatically, and the e-invoice is issued when the money arrives.

It is made of modules a business turns on as it needs them:

• Customer Support: one inbox for every channel, with an AI assistant.
• Products and orders: a catalog the AI and agents sell from inside the chat.
• Payments: VietQR bank transfers matched to orders, paid straight into the business's own account.
• E-invoices and accounting: invoices issued from paid orders, and books that follow the cash.
• Email: sending and receiving from the business's own domains.

Ha Tang serves two kinds of users. Shop owners, support teams and accountants work in the dashboard and the apps. Developers connect their own website or app through the API, SDKs and an MCP server for AI coding agents.

2. Why SotaTek Built Ha Tang

SotaTek has spent a decade building software for clients in 25 countries. When Sota Labs started building SotaTek's own consumer products, each one needed the same back office: support on many channels, payments by bank transfer, e-invoices, and transactional email.

In Vietnam that back office is harder than it looks:

• Customers spread across channels. Zalo, Facebook, TikTok and the website each have their own inbox, and the same customer appears as a stranger in each one.
• Payments arrive as bank transfers. Someone has to read the transfer note, find the order and confirm it, often late at night.
• Every sale needs an e-invoice. Issuing it by hand from a separate tool is slow and easy to miss.

Rather than stitch together a different vendor for each job, Sota Labs built one platform that does all of them on the same customer record, and opened it to other businesses as Ha Tang.

3. Key Features of Ha Tang

3.1. One Inbox for Every Channel

Messages from the website widget, the business's own mobile app, email, Zalo OA, personal Zalo, Facebook Messenger, Instagram, TikTok and TikTok Shop, WhatsApp, Telegram, LINE and X arrive in one shared inbox. The same customer is one profile across all of them, so an agent sees the whole history wherever the customer wrote.

Agents can assign conversations, leave internal notes, set reminders and schedule messages. The profile shows what the customer looked at before they wrote and what they bought after, so the team answers with context instead of asking again.

3.2. An AI Assistant That Learns from the Team

The AI assistant answers from the business's own knowledge: articles the team writes, pages of its website that Ha Tang reads and keeps up to date, and the product catalog with real prices. It can be the first responder, a draft writer for agents, or off, and it hands the conversation to a person with a summary when it can't help.

When an agent writes a better answer, one click teaches it to the AI. Questions the AI could not answer are collected in a list, so the team fills the gaps once instead of answering the same question every day.

3.3. Selling Inside the Conversation

Products, orders and payments live in the chat. The AI and agents send product cards, draft an order for the customer to confirm, and send a VietQR code for that order without leaving the conversation.

3.4. VietQR Payments Matched to Orders

Customers pay by scanning a VietQR code in their banking app, and the money goes straight into the business's own bank account, not a wallet in between. Ha Tang matches each incoming transfer to its order and marks the order paid, so nobody reads bank statements to confirm orders.

3.5. E-invoices and Accounting

When an order is paid, Ha Tang issues the e-invoice through the business's e-invoice provider. A reconciliation screen compares the money that arrived with the invoices issued and lists what is still missing, and every morning owners get an email about yesterday's money that still has no invoice.

3.6. Email on the Business's Own Domain

Ha Tang sends transactional and marketing email from the business's verified domains, with templates, broadcasts and automations. It also receives mail for the domain: support@ lands in the support inbox next to chat, and email groups forward team@ or sales@ to everyone's personal mailbox without paying for a seat per address.

4. Built for Developers and AI Coding Agents

The core of the platform is also an API, so a business can run Ha Tang behind its own website or app:

• Email API: a Resend-compatible POST /emails, an SMTP relay, React Email templates, inbound email as webhooks, and email groups.
• SDKs: the web chat widget, React and Next.js, React Native, Flutter, iOS (Swift), Android (Kotlin), Node.js, Python and a WordPress plugin.
• Webhooks: signed events for email, conversations, orders and payments.
• Docs for machines as well as people: every page of the developer hub is also served as Markdown, with an llms.txt index and an OpenAPI 3.1 spec.
• An MCP server (@hatang/mcp) lets AI coding agents such as Claude Code, Cursor and VS Code search the docs and call the API, with a read-only mode. Agent rules ship inside the npm packages, so an agent writes the integration the right way the first time.

A developer who builds a shop with an AI coding agent can add live chat, an AI assistant and VietQR checkout by asking the agent, and the agent reads the real docs instead of guessing field names.

5. Support Inside Your App, and on the Go

With the mobile SDKs, customers get help without leaving the business's own app. In the tatca.ai app, a user asks which monthly plans exist; the AI assistant answers with the real prices from the catalog and sends a product card with View and Buy buttons, then compares two plans when asked.

Agents are not tied to a desk either. Ha Tang has native apps for iPhone, Android and Mac, on the App Store, Google Play and the Mac App Store, with push notifications for new messages. From the phone an agent replies, sends a product or a payment, assigns a conversation and sees the customer's profile, the same as in the browser.

6. Who Uses Ha Tang

Ha Tang runs the back office of SotaTek's own products before it runs anyone else's.

• tatca.ai, an AI platform with more than 500,000 users on the web, iOS and Android, runs its support inbox, AI first responder, email, VietQR payments and invoicing on Ha Tang. Its AI assistant answers questions about plans and prices from a catalog of more than 30 products, and purchases from the web and the app stores sync to each customer's profile. The full story is in the tatca.ai case study.
• Hocdi.ai, the AI tutoring platform, uses Ha Tang for in-app support with an AI assistant that knows its course catalog.

The platform is built for the same kind of business outside SotaTek: online shops, education and subscription products, and service companies that sell and support customers in Vietnam.

7. How to Get Started

1. Create a free account at hatang.dev. No card is needed.
2. Connect a first channel, usually the website widget or Zalo OA.
3. Add a few knowledge articles and the product catalog, then switch the AI assistant on.
4. Link a bank account to take VietQR payments, and an e-invoice provider when you are ready to invoice.
5. Developers can start from the developer hub or the Next.js starter.

Pricing is per module, in VND, with a free plan to start. Step-by-step guides are in the help center.

Conclusion

Ha Tang gives a business one place to answer customers on every channel, sell in the conversation, get paid by VietQR and issue e-invoices, with AI taking the repetitive work. It grew out of what SotaTek's own products needed, and it now runs products with hundreds of thousands of users.

To try it, visit hatang.dev. To talk to the team about a larger rollout, write to hello@hatang.dev.