- Overseas customers will start sending questionnaires asking how you use AI, even before the law requires it.
- What you need is systems that record evidence of their own work from day one, rather than a big pile of documents.
- Interpreting the law is a job for legal advisers. Where we can help is making sure your systems actually capture the evidence.
1. Why Thai businesses should pay attention before customers start asking
What usually arrives before the law is a questionnaire from a large customer asking where you use AI, where customer data gets sent and who checks the results. Companies that can't answer within a week often lose the deal without realizing it.
Rules may apply according to the market and the impact, as well as where the developer is based. Corporate customers in Europe will send questionnaires and contract requirements down their supply chains before the rules take effect. A company with no list of its systems and no documentation may lose deals even when its product is good.
Besides the EU AI Act, there is Thailand's Personal Data Protection Act (PDPA), consumer protection law, intellectual property law and the rules of your industry. Each use case needs its own analysis. Saying “we're just an API user” doesn't mean you have no obligations.
2. The timeline to build into your product plans
The good news is that most of what you need to prepare is work a business should be doing anyway, such as knowing where data lives, who can access it and how to reverse things if the system makes a wrong decision.

According to official EU information, the rules are being phased in. Most transparency requirements and enforcement start in 2026. Requirements for some types of high-risk systems in Annex III are scheduled for late 2027, and those for high-risk AI embedded in certain regulated products are scheduled for 2028.
Companies shouldn't wait for the deadlines, because Data Governance, Quality Management, Technical Documentation and Monitoring all take time. Where a product has a long sales cycle in particular, customers may require readiness well in advance.
| Period | What businesses should do |
|---|---|
| Today to 2026 | Inventory, literacy, transparency and contracts |
| 2027 | High-risk classification, evidence, QMS and supplier readiness |
| 2028 | Product compliance, monitoring and audits according to scope |
3. Know first whether your company is a Provider, a Deployer or an intermediary
Obligations differ by role. A company that builds a system under its own name may be a Provider. A company that uses it in its processes is a Deployer. Importers and distributors may have specific obligations of their own. If you make significant changes to a system or change its Intended Purpose, your role may change, so you need a Contract Map across the whole supply chain.

Build a Use-case Inventory that records the purpose, who is affected, the decision process, the data, the models, the markets and the Human Oversight. Then have Legal classify each one. Avoid classifying risk from the name of the technology alone. The same system may carry one level of risk in marketing and a very different one when it is used to select employees.
4. Evidence you should build whatever risk level you're assigned
- The approved purpose and limitations
- Data sources, rights, quality and retention
- Model and version, vendor and change history
- Evaluation by group and by high-risk case
- Human oversight and the authority to stop or correct
- Logs, incidents, complaints and corrective action
- Explanations for users and disclosure of AI-generated content where applicable
For the development team · Technical detail
Use Documentation as Code and link evidence to each release, instead of writing documents after the fact once a year. Every change to the model, the knowledge or the Intended Use needs an impact assessment and a Decision Record.
5. Vendor contracts must deliver evidence as well as an uptime SLA
For the development team · Technical detail
Ask about Training/Data Policy, Security, Model Change, Evaluation, Subprocessors, Location, Incident Notification and Exit/Deletion. Secure the right to receive the documents your company needs to meet its obligations. If a vendor won't provide the information, you may be unable to prove that your own product complies.
For the development team · Technical detail
Tier your suppliers by impact. A model used for internal drafting and a model inside a high-risk product need different levels of due diligence. Have a Model Replacement Plan ready in case a vendor changes its terms or fails to meet requirements.
6. Transparency has to live in the UX and the process
Tell users when they are interacting with AI, as fits the context, and explain what it covers and how to reach a person. For decisions with significant impact, show the data used and, where relevant, the right to object or ask for a review. Don't hide disclaimers in long terms and conditions.
Synthetic content should carry provenance and go through approval according to risk. Create labels and metadata that survive through downstream channels, train staff not to over-rely on AI, and have a script for explaining things to customers honestly.
7. Build a compliance program that doesn't become a bottleneck
For the development team · Technical detail
Use a Risk-tier Workflow: self-assessment for low risk, review by Data/Security for medium risk, and a cross-functional assessment for high risk. Create templates, approved patterns and a sandbox so teams can move fast within the guardrails. Legal should be involved from the design stage instead of on the last day before go-live.
For the development team · Technical detail
Set up an AI Governance Committee of a sensible size that focuses on policy and exceptions and doesn't approve every prompt. Keep an AI Register with owners, review dates and a dashboard of incidents and evidence. Check what actually happens in practice by sampling.
8. What you can do today without waiting for every line of the law to be clear
- Register every AI system and the markets it touches.
- Name the owner, the intended use and an initial risk level.
- Create data and model lineage and version records.
- Define human oversight, incident handling and complaint handling.
- Add AI clauses to procurement and vendor contracts.
- Have Legal review the key use cases and your market roadmap.
In short: Thai businesses that sell abroad should prepare evidence and governance before customers or the rules force them to. Inventory, classification, lineage, evaluation and human oversight are a useful foundation however the law changes. The aim is a system that can be explained, controlled and corrected, rather than documents produced just to pass a checklist.
European Commission: Navigating the AI Act
Build a record of how your systems work that answers customers and auditors from day one
Interpreting legal requirements is the job of your legal advisers and compliance team, and a software company shouldn't be doing it for you. What DNA Maker can do is take the requirements your team has already worked out and turn them into things the system does automatically, such as recording which data set a decision used, keeping the versions of the model and rules in use at the time, asking for consent and recording it, and making it clear to users that they're talking to an automated system. These should be by-products of normal work, instead of extra work someone has to chase down later.
What the system should record for you automatically
The systems we design usually have a logging layer kept separate from the core logic, so you can change the model or provider and the evidence stays continuous. There's a dashboard where the compliance team can pull reports themselves without waiting for developers, and a test suite that can be re-run after every change to prove that quality hasn't slipped. If overseas customers are starting to send you questionnaires about your use of AI, and you have to chase several teams before you can answer, that's where a system really helps.
SOFTWARE ENGINEERING GLOSSARY
Software engineering glossary
These terms help you talk with the development team about evidence and looking back to audit what happened.
| Term | What it is | A simple example | What executives should ask the development team |
|---|---|---|---|
| Traceability | The ability to trace which data and rules a particular result came from | Being able to see which version of the criteria was used to reject this request | How far back can we trace, and how long do we keep the records? |
| Versioning | Keeping versions of models, rules or documents so you know what was in use at a given time | Recording that last month the system used version 3 of the rules | If we had to explain a result from three months ago, would we have enough information? |
| Consent | Asking for and recording a user's consent before collecting or using their data | Recording when a customer agreed to have their conversation stored | How can we prove consent after the fact? |
| PII | Information that can identify a person and needs special care | A customer's name, phone number and document numbers | Which systems outside our own is personal data sent to? |
| Model Card | A document summarizing what a model is used for, its limitations and how it was evaluated | A summary of the scope of use and the cases where it shouldn't be used | Do we have a document like this for the systems we use? |
