バンコク AI 会社を比較する際、デモの見栄えや開発単価だけでは、本番導入後の品質と運用負荷を判断できません。重要なのは、課題定義、タイ語データ、既存システム連携、PDPA、AIガバナンス、受入試験、ソースコードと運用の引継ぎまでを一つの調達として評価することです。本記事では、タイの日系企業が候補選定からRFP、PoC、FAT/UAT、本番SLAまでを証拠に基づいて進める実務を整理します。
結論：バンコクのAI開発会社は「作れるか」より「受け入れられるか」で選ぶ
AI案件の失敗は、モデルが一度も動かなかったときだけに起きるのではありません。試作は動いたのに現場のタイ語表記へ対応できない、ERPのマスター変更で精度が崩れる、生成AIの回答根拠を追えない、担当ベンダーしかプロンプトや評価手順を更新できない、といった状態も事業としては失敗です。
したがって選定の中心は、モデル名やデモ精度ではなく、次の五つです。
- 解く業務課題と、AIを使わない代替案を説明できるか。
- データ、権利、PDPA、安全、セキュリティの責任分界が明確か。
- 日本語・タイ語・英語が混在する実データで再現可能な評価を行えるか。
- ERP、MES、文書、設備、承認フローへ安全に組み込めるか。
- FAT/UAT後に顧客側が監視・変更・復旧できる形で引き渡せるか。
この考え方は、AIを単発の受託開発ではなく、継続的に監視・改善する業務システムとして調達するものです。外注範囲を先に整理したい場合はタイにおけるAI開発委託の実務を、検証計画を詳しく作りたい場合はAI PoCの費用項目と成功基準を参照してください。
なぜ今、タイ AI開発の会社選定を厳しくすべきか
Thailand BOIの2026年上期発表では、投資申請額は1.47兆バーツ、申請件数は1,299件、金額は前年同期比37%増でした。これは承認額、実行済み投資額、AI案件だけの金額ではなく、上期の投資申請全体を示す数字です。BOIは2026年8月にもAI・デジタル分野への流入と、国家半導体・先端エレクトロニクス戦略に関する動きを発表しており、タイで計算基盤、クラウド、デジタルサービスを含む投資環境が動いていることは確認できます。
しかし、市場が伸びることと、自社案件に適した会社を選べることは別問題です。「AI対応」「生成AI開発」「エージェント構築」という看板だけでは、データ越境、タイ語評価、現場定着、監査ログ、モデル更新、障害復旧への対応力は分かりません。発注側が比較可能な資料を用意しなければ、各社は異なる前提で提案し、価格も納期も評価指標も比較できなくなります。
ETDAはAIガバナンスを信頼できるAI利用の基盤として推進し、AIGPCを通じて組織向けのガバナンス支援を提供しています。またISO/IEC 42001は、AIマネジメントシステムを組織として確立・運用・改善するための要求事項を扱います。これらは特定モデルの精度を保証する制度ではありませんが、役割、リスク、記録、監視、継続改善を会社選定へ入れる根拠になります。
バンコク AI 会社の候補を4類型に分ける
会社名の知名度より、案件に必要な能力の組み合わせを見ます。候補は大きく四類型に整理できます。
| 類型 | 強みになりやすい領域 | 確認すべき弱点 |
|---|---|---|
| AI専業・スタートアップ | モデル検証、生成AI、速度、専門人材 | ERP連携、長期保守、財務・要員継続性、引継ぎ |
| SI・業務システム会社 | 要件定義、ERP/MES/API、運用、契約管理 | AI評価の深さ、最新手法への追随、実験速度 |
| クラウド／製品パートナー | 基盤、セキュリティ、標準サービス、拡張性 | 製品ロックイン、個別業務適合、利用量増加時の費用 |
| 現地工場・OTに強い会社 | 現場、設備、ネットワーク、保全、タイ語対応 | データサイエンス、生成AI評価、MLOpsの実績 |
一社ですべてを満たすとは限りません。元請け、AI専門会社、クラウド、OTインテグレーターの連合になる場合は、障害時の一次窓口と最終責任を一社に決め、再委託先の変更条件も契約します。顧客が各社の間を調整する構造は、障害復旧と変更管理を遅らせます。
AI開発会社の評価表：提案前に配点と失格条件を固定する
提案書を読んだ後に評価項目を決めると、印象や営業関係に引っ張られます。RFP配布前に、配点、最低点、失格条件、証拠形式を固定します。次は100点満点の例示であり、業界標準ではありません。案件のリスクに応じて変更してください。
| 評価領域 | 例示配点 | 求める証拠 |
|---|---|---|
| 業務理解と価値仮説 | 15 | 現状業務図、KPI定義、AIを使わない代替案 |
| データ・タイ語対応 | 15 | データ診断、タイ語評価セット、欠損・偏りの扱い |
| AI品質・評価設計 | 15 | ベースライン、再現可能なテスト、誤り分類 |
| 連携・アーキテクチャ | 15 | API、権限、監査、ERP/MES連携、障害時設計 |
| セキュリティ・PDPA | 15 | データフロー、処理者、保存場所、削除、事故対応 |
| 運用・SLA・引継ぎ | 15 | 監視、復旧、ソース、文書、教育、要員体制 |
| 商務・継続性 | 10 | 見積前提、変更単価、ライセンス、再委託、財務体制 |
| 合計 | 100 | 同じテンプレートで比較する |
失格条件の例は、機密データを承認なく外部学習へ使う、データ保存国を回答できない、重大インシデントの通知手順がない、成果物の権利と利用条件を明示しない、検証データを本番データと同じ集合から作る、といったものです。失格条件も法的結論ではなく、自社の情報分類とリスク方針に合わせます。
スコアは営業説明だけで付けません。「あります」ではなく、匿名化したサンプル、画面、テスト記録、構成図、運用手順、担当者面談で裏付けます。過去案件の数より、自社と似た制約の案件で何を失敗し、どう直したかを聞く方が実力を見極めやすくなります。
RFPでタイ AI導入の前提を揃える
良いRFPは、完成仕様を発注者がすべて決める文書ではありません。各社が同じ問題へ提案し、未確定事項を明示できる比較基盤です。最低限、次を含めます。
1. 業務範囲と除外範囲
対象ユーザー、拠点、言語、入力、出力、承認者、利用時間、ピーク量、既存システムを記載します。「問い合わせ対応をAI化」ではなく、「タイ語・日本語の保守問い合わせを分類し、根拠文書付きの回答案を作り、人が承認して送信する」のように境界を示します。自動送信、価格決定、人事判断など、PoCで行わないことも明記します。
2. 現状値と目標値
現在の処理時間、件数、再作業、誤分類、欠損、待ち時間を測ります。数値が無い場合は、最初の調査期間で基準値を作ることを成果物にします。「精度95%」のような単独指標は避け、重要な誤りと許容できる誤りを分けます。たとえば設備停止に関する回答の見逃しは、一般的な言い換えミスより重大です。
3. データ一覧と利用条件
データ所有者、形式、期間、言語、個人データ、機密区分、保存場所、更新頻度、欠損、ラベル有無を一覧化します。データをまだ渡せない段階では、列名を伏せたスキーマ、件数帯、例示レコード、情報分類だけでも共有し、ベンダーに仮定を書かせます。
4. 連携と非機能要件
ERP、MES、CRM、SharePoint、ファイルサーバー、メール、設備データなどの接続方式、認証、ネットワーク区分、同時利用、応答時間、監査ログ、保守時間帯、バックアップ、復旧目標を示します。応答時間や復旧時間は、現状の業務許容時間とシステム重要度から決め、根拠のない万能値を置きません。
5. 成果物と受入方法
ソースコードだけでなく、データ辞書、プロンプト、システムプロンプト、評価データ、評価スクリプト、モデル／サービス構成、IaC、設定、API仕様、運用手順、障害対応、管理者教育、ライセンス台帳、既知の制約を列挙します。各成果物に形式、更新責任、受入者を割り当てます。
PoCは「できる」を示す試作ではなく、Go/No-Goの不確実性を減らす
PoC前にタイ企業向けAI導入ロードマップで全体段階を整理すると、PoCだけが独立した実験になるのを防げます。PoCの質問は「AIで可能か」では広すぎます。次のように、意思決定へつながる問いへ変えます。
- タイ語の略語、綴り揺れ、英数字混在でも、重大カテゴリを許容範囲で分類できるか。
- 回答根拠を承認済み文書へ限定し、根拠が無い場合に回答を保留できるか。
- 実際のAPI権限とネットワーク条件で、ERPへ二重登録せず連携できるか。
- 利用量が増えた場合の処理時間と費用構造を測れるか。
- 担当者がプロンプト、知識、閾値を更新し、ロールバックできるか。
PoCの段階ゲート
期間は案件ごとに異なります。以下は段階設計の例であり、固定納期や市場標準ではありません。
| ゲート | 確認すること | 残す証拠 |
|---|---|---|
| G0 課題確認 | 利用者、判断、現状値、代替案 | 業務図、基準値、リスク一覧 |
| G1 データ実現性 | 品質、権利、言語、代表性 | データ診断、除外記録、評価セット仕様 |
| G2 技術実現性 | ベースラインとの差、重大誤り | 再現手順、結果表、誤り分類 |
| G3 業務適合 | 人の承認、例外、教育、操作性 | シナリオ記録、利用者コメント |
| G4 本番適合 | セキュリティ、性能、監視、費用 | 負荷試験、データフロー、運用見積 |
| G5 投資判断 | 便益、残留リスク、次段階 | Go/条件付きGo/No-Go判定書 |
評価データは、開発中に答え合わせで使うデータと分離します。重要カテゴリ、低頻度ケース、タイ語の口語、OCR誤り、古い文書、矛盾する文書、攻撃的入力も含めます。生成AIの場合は正解が一つでないため、完全一致だけでなく、根拠の正しさ、禁止事項、網羅性、保留判断、人による再作業を評価します。
NISTのAI RMF Generative AI Profileは、生成AI固有のリスクをAI RMFへ適用するための補助資料です。認証や製品ランキングではありませんが、リスクの把握、測定、管理をPoCのテストへ落とす参考になります。OWASP Top 10 for LLM Applications 2025も、prompt injection、sensitive information disclosure、supply chain、data and model poisoning、improper output handling、excessive agencyなどを含む確認観点を提供します。チェックリストを貼るだけでなく、自社のデータフローと権限で攻撃シナリオを作ることが重要です。
タイ語運用をデモ翻訳で済ませない
タイ AI開発では、画面をタイ語化することと、タイ語の業務品質を保証することを分けます。現場データには、ไทยとEnglishの混在、製品コード、ローマ字、社内略語、敬語の差、口語、音声転記、OCR誤りが含まれます。日本人管理者の日本語と、タイ人担当者のタイ語で同じ事象を別の言葉で呼ぶこともあります。
評価セットは、実際の拠点・部門・シフトを代表するように層化します。翻訳した日本語だけではなく、タイ語で最初から作られた問い合わせ、手順書、帳票を含めます。評価者も、言語能力だけでなく業務知識を持つ人を入れます。タイ語の正しさと、保全・品質・購買などの業務判断の正しさは別だからです。
運用では用語集、禁止表現、承認済み回答、言語別プロンプト、評価セットを版管理します。新製品、新工程、法令、組織変更の際に誰が更新し、どのテストを再実行するかを決めます。多言語モデルを採用したという説明だけでは受入条件になりません。
製造業DX×AIではOTと安全を評価範囲に入れる
製造業でAIが設備、品質判定、作業指示、生産計画へ関与する場合、一般的なWebアプリより影響が大きくなります。AIの出力をPLCへ直接書き込むのか、人や既存ロジックが承認するのか、異常時に安全側へ止められるのかを構成図で示します。
初期段階では、AIを助言層に置き、決定論的な安全制御や設備インターロックと分離する設計が選択肢になります。どの構成が適切かはリスクアセスメント次第であり、AIがあるだけで自動的に安全性が高まるとは限りません。モデル更新後は精度テストだけでなく、設備への出力範囲、タイムアウト、異常値、手動切替を回帰試験します。
depaのAI & Digital Transformation Catalogは、タイで検討可能なAI・デジタルソリューションを調べる入口として利用できます。ただし掲載自体を品質保証、法令適合、TOMAS TECHによる推奨とみなさず、RFPと受入試験で個別評価します。
データ権利とPDPAを契約本文へ落とす
PDPA対応は「準拠します」という一文では不足です。タイの法的要件は案件ごとに専門家へ確認する必要がありますが、技術・契約面では少なくとも次を明示します。
- 誰がデータ管理者・処理者に該当する想定か、再委託先は誰か。
- 個人データを何の目的で処理し、どの項目を最小化するか。
- 原文、埋め込み、ログ、バックアップ、評価データをどの国・サービスへ保存するか。
- 基盤提供者が入力をモデル学習へ利用する設定か、オプトアウト条件は何か。
- 保存期間、削除方法、バックアップからの消去方針、契約終了時の返却をどうするか。
- アクセス、ダウンロード、管理操作を誰が行い、どのログを残すか。
- 漏えい・誤送信・越境・再識別の事故時に、誰がいつ誰へ連絡するか。
データの所有権と、学習済み成果の利用権も分けます。顧客原データ、顧客が作成したラベル、ベンダーの既存ライブラリ、顧客専用コード、汎用改善、プロンプト、微調整重み、評価セット、生成物について、所有・利用・再利用・第三者提供の条件を資産別に定義します。「成果物一式は顧客所有」の一文では、クラウドAPIやOSS、再利用部品との関係が曖昧です。
ソースコード、モデル、運用引継ぎの受入条件
Gitリポジトリを渡されても、ビルドできず、本番権限がベンダー個人に残り、評価データが無ければ引継ぎは完了していません。受入時にはクリーンな環境から顧客管理のアカウントへ展開し、バックアップから復旧し、代表テストを再実行します。
引継ぎ対象は次のように層別します。
| 層 | 引継ぐもの |
|---|---|
| コード | アプリ、連携、評価、移行、IaC、依存関係、ビルド手順 |
| AI設定 | モデル名・版、パラメータ、プロンプト、ガードレール、ルーティング |
| データ | 辞書、スキーマ、ラベル規則、評価セット、出所、権利、保持条件 |
| 環境 | 顧客所有アカウント、権限表、秘密情報の保管方法、ネットワーク図 |
| 運用 | 監視、アラート、インシデント、変更、再評価、ロールバック、費用監視 |
| 知識 | 管理者・利用者教育、録画、FAQ、既知の制限、未解決課題 |
ソースコードのエスクローが必要か、契約終了時に移行支援を何時間含めるか、主要担当者が離任した場合の代替要員をどうするかも検討します。OSSと外部モデルのライセンス、API利用規約、サポート終了も台帳化します。
FAT・UAT・受入試験を一つの証拠体系にする
AI案件では、FATをベンダー環境での機能・連携確認、UATを利用者による業務適合確認として分けられます。ただし名称より、どのリスクをどの環境で、誰が、どのデータで確認するかが重要です。
FATで確認すること
FATでは、固定したコード・モデル・プロンプト版で、API、権限、入力検証、ログ、エラー、タイムアウト、再送、二重処理防止、バックアップを確認します。外部AIサービスが停止、遅延、利用上限へ到達した場合の動作も試します。生成出力を別システムへ渡す場合、OWASPが指摘するimproper output handlingを踏まえ、出力を命令やSQLとして無検証で実行しないことを確認します。
UATで確認すること
UATでは、実際の日本人・タイ人ユーザーが、正常、曖昧、欠損、禁止、低信頼、権限外のシナリオを操作します。正解率だけでなく、根拠の確認しやすさ、修正時間、保留・エスカレーション、アクセシビリティ、教育負荷を記録します。承認者がAIの誤りを見抜けない画面は、人を入れても安全なhuman-in-the-loopとは言えません。
受入記録の形
各テストケースに、前提、入力、操作、期待結果、実結果、証跡ID、構成版、判定者、残課題を持たせます。合格閾値はRFPまたはPoC終了時に合意し、結果を見てから緩める場合は、理由と残留リスクを承認します。重大ケースの不合格を平均点で相殺しないルールも必要です。
SLAは稼働率だけでなくAI品質と変更を含める
クラウドが動いていても、回答根拠が古い、タイ語分類が崩れた、API費用が急増したなら業務サービスは健全ではありません。SLAと運用指標を三層に分けます。
- システム層：可用性、応答、エラー、キュー、連携、バックアップ、復旧。
- AI品質層：重大誤り、根拠なし回答、保留率、ドリフト、言語別性能、再作業。
- 業務層：処理時間、滞留、利用率、承認時間、顧客・現場への影響。
すべてを違約金付きSLAにする必要はありません。保証値、運用品質目標、観測指標を分けます。外部モデルやクラウドの障害がある場合、ベンダーが免責されるかどうかだけでなく、通知、縮退運転、代替モデル、手作業への切替、データ整合を誰が行うかを決めます。
変更管理では、モデル版、プロンプト、知識文書、検索設定、閾値、コード、データスキーマを構成品として扱います。軽微な文言修正でも重要テストへ影響する場合があります。変更前後の評価、承認、公開、監視、ロールバックを一つのリリース記録へ残します。
AIガバナンスを会社評価へ組み込む質問
ISO/IEC 42001やETDAのガバナンス方向性を、認証の有無だけで判断しないことが重要です。認証範囲が自社案件と一致するかも含め、実務を質問します。
- AI利用台帳に案件、モデル、データ、所有者、リスク、利用者を登録するか。
- 重大影響のユースケースを誰が承認し、停止できるか。
- 設計時、導入時、運用時にリスク評価をいつ更新するか。
- モデルカード、データ記録、評価結果、変更履歴をどう保存するか。
- 公平性、説明可能性、プライバシー、安全、セキュリティを誰がレビューするか。
- 利用者へAIであること、制約、問い合わせ先をどう知らせるか。
- 誤回答、情報漏えい、prompt injection、過剰な自動実行をどう検知・封じ込めるか。
- 外部モデル提供者の仕様変更と終了をどう監視するか。
AIエージェントがメール送信、受発注、設備指示、ファイル削除などのツールを使う場合は、権限を最小化し、高影響操作に承認を置き、引数と結果を監査します。OWASPのexcessive agencyという観点は、エージェントに必要以上の機能・権限・自律性を与えない設計へつながります。
見積比較では総額より前提差を揃える
AI開発会社の見積は、同じ表題でも含む範囲が違います。要件定義、データ整備、ラベル、翻訳、API、クラウド、モデル利用、セキュリティ試験、ユーザー教育、ハイパーケア、保守を項目別にします。金額の架空相場は置かず、各社が同じ数量前提を記入する価格表を用意します。
| 費用層 | 数量・前提として揃える項目 |
|---|---|
| 初期調査 | 対象部門、面談回数、データソース、現場訪問、言語 |
| 構築 | 画面、API、ワークフロー、モデル候補、環境数、移行 |
| データ | 件数、ページ数、音声時間、ラベル、OCR、翻訳、匿名化 |
| 基盤 | 開発・検証・本番、ログ期間、保存量、ネットワーク、GPU |
| 利用量 | リクエスト、token、文書検索、同時実行、ピーク、再処理 |
| 運用 | 監視時間、問い合わせ、障害、再評価、モデル変更、報告 |
| 終了・移行 | データ返却、削除証明、文書更新、教育、移行支援 |
単価だけでなく、数量が増えたときの階段、為替、最低利用、解約、前払い、第三者サービス値上げ、変更要求の算定方法を確認します。PoC価格を本番価格と誤認せず、本番利用量の低・基準・高シナリオを顧客の実測で更新します。
日系企業 タイ AIの意思決定体制
日系企業のタイ拠点では、日本本社、タイ法人、現場、IT、法務・人事、地域統括が関わります。全件を本社承認にすると遅くなり、現地だけで決めるとグループ基準や契約と衝突します。RACIを作り、ユースケース所有者、データ所有者、技術所有者、リスク承認者、予算責任者を分けます。
言語も責任の一部です。日本語議事録だけで重要条件を決めず、タイ語利用者が受入条件と禁止事項を確認できるようにします。契約本文が英語でも、運用手順、事故連絡、画面、教育を現場言語へ落とします。翻訳版間に差がある場合の正本と、変更時の同期責任も決めます。
ステアリング会議では、進捗率だけでなく、仮定、未解決リスク、評価結果、データ権利、費用予測、Go/No-Go条件を確認します。赤信号を早く出したベンダーを低評価にする文化では、問題が受入直前まで隠れます。課題の早期開示と再現可能な証拠を評価する調達に変える必要があります。
契約前の最終チェックリスト
- 対象業務、対象外、自動化レベル、最終判断者が明確か。
- 主な利用者、拠点、タイ語・日本語・英語の評価方法が決まったか。
- データの目的、保存国、再委託、学習利用、削除、返却が契約にあるか。
- 顧客データ、ラベル、コード、プロンプト、評価セット、生成物の権利が資産別にあるか。
- AIを使わないベースラインと重大誤りの定義があるか。
- PoCのGo/No-Goゲートと、本番化しない場合の終了条件があるか。
- FAT/UATの環境、データ、判定者、証拠、構成版があるか。
- ERP/MES/APIの二重処理、タイムアウト、再送、取消し、整合手順があるか。
- prompt injection、情報漏えい、過剰権限、出力検証を試験するか。
- SLA、縮退運転、通知、復旧、変更、モデル終了時の代替があるか。
- 顧客管理アカウントへ展開し、ソース、設定、文書、教育を受け取れるか。
- 契約終了時にデータ・秘密情報を返却／削除し、別会社へ移行できるか。
FAQ
バンコク AI 会社は何社くらい比較すべきですか？
普遍的な社数はありません。最初に情報提供依頼で能力と失格条件を確認し、RFPは十分に比較でき、かつ質疑と評価を管理できる数へ絞ります。社数より、異なる類型を含め、同じ前提・証拠形式で比較することが重要です。
タイ AI開発のPoC費用はいくらですか？
データ整備、連携、言語、セキュリティ、評価範囲で大きく変わるため、根拠のない相場を一律提示できません。成果物分解、役割別工数、第三者利用料、数量前提、変更単価を揃えて比較してください。安価なデモと、本番判断に必要なPoCは別物です。
AI開発会社へ機密データを渡しても安全ですか？
会社名だけで安全とは判断できません。必要最小限のデータ、匿名化、顧客管理環境、権限、保存国、学習利用設定、ログ、削除、事故通知、再委託を確認し、段階的に提供します。法的評価はタイの専門家と確認してください。
タイ AI導入でタイ語精度はどう評価しますか？
翻訳したテストだけでなく、実際のタイ語、英語混在、略語、OCR誤り、低頻度の重大ケースを含む独立評価セットを作ります。業務知識を持つタイ語話者が、正しさ、根拠、保留、再作業を評価します。
日系企業 タイ AIでは本社と現地のどちらが責任を持ちますか？
一方へまとめるのではなく、ユースケース、データ、技術、リスク、予算ごとに責任者を決めます。本社標準とタイの運用・法的要件を両方満たし、現地利用者をUATと変更承認へ入れることが重要です。
AIエージェントを最初から自動実行にしてよいですか？
影響が小さく可逆な操作から始め、権限を限定し、承認、上限、監査、停止手段を置くのが現実的です。支払い、顧客送信、設備操作、削除など高影響の操作は、リスク評価と受入証拠なしに広い自律性を与えないでください。
まとめ：比較表を「納品後も自社で運用できるか」へつなげる
バンコクでAI開発会社を選ぶときは、デモ、単価、モデル名ではなく、業務価値、タイ語データ、連携、PDPA、AIガバナンス、FAT/UAT、SLA、権利、引継ぎを同じ証拠形式で比較します。PoCは成功演出ではなく、本番化の不確実性を減らすゲートです。最終受入では、顧客管理環境で展開・評価・復旧でき、担当会社が変わっても運用を継続できることまで確認します。
候補比較表やRFPの作成段階でも、対象業務と既存システムが分かれば論点を具体化できます。タイ語運用、製造現場、ERP/MES連携を含むAI導入の検討は、TOMAS TECHのお問い合わせページからご相談ください。
参考情報
- Thailand BOI, Thailand Secures 1.47 Trillion Baht in Investment Applications in 1H 2026: https://osos.boi.go.th/EN/news/2430/Thailand-Secures-43-6bn-1H-2026-Investment-Surge-as-Big-Tec/
- Thailand BOI, Thailand AI and Tech Inflows Surge: https://osos.boi.go.th/EN/news/2462/Thailand-AI-and-Tech-Inflows-Surge-as-Country-Prepares-Natio/
- ETDA, Driving Trust with AI Governance: https://www.etda.or.th/th/pr-news/aigc_Driving-Trust_AI_Governance.aspx?feed=cb66f430-5546-4dd8-b279-3827e88d154b
- ETDA, AI Governance Practice Center (AIGPC): https://www.etda.or.th/th/Our-Service/AIGC/index.aspx
- ISO, ISO/IEC 42001:2023 Artificial intelligence management system: https://www.iso.org/standard/42001?browse=ics
- NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence
- depa, AI & Digital Transformation Catalog: https://www.depa.or.th/storage/app/media/file/ai-digital-transformation-catalog.pdf
- OWASP, Top 10 for Large Language Model Applications 2025: https://genai.owasp.org/llm-top-10/
