Blog

2026.09.07

ベトナム AI 導入2026|AI法対応RFPと90日PoC設計

ベトナム AI 導入2026|AI法対応RFPと90日PoC設計

ベトナム AI 導入2026|AI法対応RFPと90日PoC設計

ベトナム AI 導入を2026年に進める企業は、製品比較より先に「用途、リスク、データ、人の介入、変更、証跡」を一枚の調達要件へまとめる必要があります。AI法の施行後は、PoCで精度が出たという理由だけでは本番移行を判断できません。本稿では、ベトナム工場や現地法人でAIを発注する本社・現地経営・IT・法務・調達向けに、最新の一次情報をRFP、90日PoC、受入、運用へ変換する方法を解説します。

先に結論|製品選定前に8項目を一枚のRFPへ

最初に作るべき成果物は、製品比較表ではありません。次の8項目を同じ行で追える「AIユースケース/統制台帳」です。

  1. ユースケース棚卸し:誰のどの判断・作業を、どの入力と出力で支援するか。
  2. AI法リスク分類:高・中・低のどこに分類するか、根拠と判定者は誰か。
  3. Decision 33該当性:高リスク一覧への該当可能性を誰が法務確認したか。
  4. 個人データと越境フロー:入力、ログ、評価データ、保管、閲覧、再委託、国外移転をどう流すか。
  5. provider/deployerの責任境界:モデル、アプリ、運用、判断、事故対応を誰が担うか。
  6. human-in-command:どの時点で人が確認し、介入し、拒否し、停止できるか。
  7. 変更時再分類:用途、データ、モデル、統合先、利用者が変わったとき、誰が再評価するか。
  8. 証跡と出口:ログ、版、承認、停止、ロールバック、データ返却・削除、他社移行をどう証明するか。

この8項目は独立したチェックリストではありません。一つの用途について、分類結果が人の介入方法を決め、人の介入方法が画面・権限・ログを決め、データフローが契約条項とPoCの試験条件を決めます。別々の部署が別々のExcelで管理すると、製品契約時に接続が切れます。RFPの一行を受入試験ID、運用手順、変更申請、事故記録まで引き継ぐ設計が重要です。

ベトナムの2026年AI制度を調達条件へ翻訳する

ベトナムのAI Law 134/2025/QH15は2025年12月10日に発行され、2026年3月1日に施行されました。実施に関するDecree 142/2026/NĐ-CPの政府公式概要は、AIシステムをhigh/medium/lowの3段階で扱い、providerが利用前に自己分類することを示しています。Decree 142本文Article 13は、目的や統合などの重大な変更後に高リスクシステムの適合性を再評価する場面を定めています。すべてのシステムについて法定のリスク分類をやり直す義務と一般化せず、本稿のより広い分類影響レビューは調達者の変更管理上の提案として扱います。

また、Decision 33/2026/QĐ-TTgは2026年6月30日に発行され、8月15日に施行された高リスク一覧に関する決定です。本稿では、提示された一次情報だけでは一覧の具体的な収載カテゴリを確認できないため、業務分野を列挙して「該当する/しない」と断定しません。対象候補の業務、利用者、判断への影響、入力データ、出力の使われ方を資料化し、ベトナムの有資格専門家へ条文と最新運用を確認できる状態を作ることが実務上の第一歩です。

Circular 05/2026/TT-BKHCNに関する科学技術省の英語概要は、システムの影響に応じて人の監督と介入を確保する倫理枠組みを説明しています。ここから調達へ翻訳すべき問いは、「human-in-the-loopという言葉が提案書にあるか」ではなく、「誰が、何を見て、何秒・何時間以内に、どの権限で、どの結果を止められるか」です。

個人データについては、Decree 356/2025/NĐ-CPが2025年12月31日に発行され、2026年1月1日に施行されています。Personal Data Law 91/2025/QH15と合わせ、少なくとも契約前に、プロンプトや業務入力、会話・操作ログ、評価データ、添付文書、利用者識別子、国外のモデルAPIや保守担当への流れを地図化します。個別の法的義務や手続は用途・当事者・データにより判断が変わるため、本稿は法的助言ではありません。社内法務、DPO・セキュリティ担当、ベトナムの専門家に最新本文と適用関係を確認してください。

新しい国家AI戦略が示す「実験から経営能力へ」の転換

Decision 1671/QĐ-TTgは2026年8月28日に発行され、旧Decision 127/QĐ-TTgを置き換えました。2026年9月4日の政府説明は、AIを単発ツールとして導入するのではなく、課題定義、設計、組織、運用から中核能力として扱い、人材、インフラ、データ基盤、制度とガバナンスを重視する方向を示しています。

この政策方向を企業実務へ置き換えると、「チャット画面を配布する」だけでは足りません。経営課題から用途を選び、現場データを整え、責任者と停止権限を決め、利用後の改善まで回す能力が必要です。2026年9月1日には科学技術省が、Qualcommがベトナムを将来のAIハブの一つとする意向と協力案を提示したことを報じました。ただし、これは協力提案と意向であり、投資完了や政府保証を意味しません。ベンダー選定で政策ニュースを需要保証や補助金確約のように扱わず、自社の契約・データ・運用条件を評価してください。

use case inventory|「AIを入れる」から判断単位へ分解する

最初のワークショップで製品名を議題にしないことが重要です。現場が困っている判断と作業を、次の粒度で棚卸しします。

項目記録する内容RFPへ渡す証拠
業務目的不良原因の探索、保全問合せ、帳票読取など現行フローと課題記録
利用者作業者、班長、品質、保全、管理者、顧客役割と権限表
入力文書、画像、センサ、ERP/MES、自由文サンプル、機密区分、データ所在
出力推薦、要約、分類、生成文、制御候補出力例と禁止出力
判断への影響参考、要確認、承認材料、自動実行人の確認点と停止条件
誤りの影響手戻り、品質、停止、安全、権利、情報漏えい影響シナリオと回復方法
利用規模拠点、部署、シフト、言語、利用頻度ピーク条件と対象範囲
オーナー業務、データ、システム、リスクの責任者RACIと承認記録

たとえば「保全AI」は一用途ではありません。マニュアル検索、過去故障の類似検索、点検記録の要約、交換部品の推薦、停止判断の補助では、入力と影響が異なります。自動制御へ接続しなくても、誤った推薦が現場の停止判断に使われれば影響は大きくなります。反対に、社内用語の翻訳支援でも、顧客情報や従業員情報を外部APIへ送ればデータ面の検討が必要です。

棚卸しには「現時点でAIを使わない」判断も残します。正解データがない、責任者がいない、停止できない、既存ルールで十分、入力品質が低すぎる用途は、製品評価前に保留できます。候補数を増やすより、検証可能な用途へ絞る方がRFPの比較可能性を高めます。

AI法リスク分類をベンダー任せにしない

Decree 142の公式概要がproviderによる利用前の自己分類を示していても、導入企業は回答を受け取るだけでは不十分です。providerが想定する用途と、工場が実際に使う用途がずれる可能性があるためです。RFPでは少なくとも次を回答させます。

  • 提案システムの分類結果、判定日、対象バージョン、想定用途、除外用途。
  • 分類に用いた前提、入力・出力、利用者、統合先、人の監督方法。
  • Decision 33との照合を行った主体と、確認に使った法令版。
  • 顧客側の設定、追加学習、RAG、API接続、目的変更が分類へ与える影響。
  • 分類が変わる可能性を検知し、通知し、再評価する手順。
  • provider以外のモデル提供者、クラウド、再委託先が変わる場合の通知。

導入企業側も独自の「用途カード」を添付します。ベンダーの分類対象がモデル単体なのか、アプリと業務統合を含むのかを合わせます。「低リスクモデルを使っているから業務も低リスク」と短絡しないことが重要です。分類の法的結論は専門家へ確認しつつ、判断材料の整備、版管理、変更検知はプロジェクト管理として実装できます。

ベトナム AI 導入2026|AI法対応RFPと90日PoC設計 - figure 1

個人データと越境フローを契約前に一枚へ描く

生成AIでは、学習データだけを確認しても不十分です。入力、検索インデックス、埋め込み、プロンプト、出力、フィードバック、評価データ、監視ログ、障害解析用コピー、バックアップまで追います。次の列を持つデータフロー台帳を作ります。

データ段階確認事項受入証拠の例
取得出所、目的、本人・取引先との関係、機密区分データカタログ、取得フロー
前処理マスキング、匿名化、分割、OCR、翻訳変換仕様とサンプル結果
送信送信先国・サービス・API、暗号化、再送構成図、通信ログ、契約範囲
推論保持、再利用、学習利用の有無、隔離設定証跡、provider回答
ログ本文・識別子・エラーの記録範囲ログ項目表、アクセス権
評価誰が何を正解として採点するか評価セットの由来と版
保守調査者、遠隔アクセス、再委託承認ログ、作業記録
終了返却、削除、バックアップ、派生物削除証明、出口手順

「ベトナム国内サーバー」という回答だけで判断しないでください。モデルAPI、監視、サポート、ログ分析、バックアップ、ID基盤が別の場所にあれば、全体の流れは国内で閉じません。逆に越境があることだけで直ちに可否を決めるのではなく、データ、目的、当事者、契約、保護策を法務・セキュリティと評価します。

評価データも見落とされやすい項目です。PoC担当者が「良い回答/悪い回答」を付けると、そのデータに元の質問、文書、担当者名、顧客情報が残る場合があります。評価SaaSや海外ベンダーへ共有する前に、入力本体と同じフロー台帳へ載せます。

provider/deployerの責任境界をRACIではなく動詞で書く

責任表に「ベンダー:システム、顧客:運用」とだけ書くと、事故時に機能しません。次の動詞ごとに、実行、承認、通知、証拠保管を分けます。

動詞provider側の確認例deployer側の確認例
classify製品・版・想定用途の分類と根拠実用途・統合後の適用確認
configure安全設定、フィルタ、ログ、権限の提供値の承認、職務別割当、変更管理
monitorサービス・モデル・脆弱性の監視業務品質、逸脱、誤用、現場影響の監視
intervene技術的停止、版戻し、障害封じ込め出力拒否、業務停止、代替手順への切替
investigate技術ログ解析、原因・影響の説明業務事実、対象者、データ、判断履歴の確認
notifyモデル・条件・再委託・事故の通知利用者・経営・法務・関係先への連絡判断
restoreサービス、設定、データの復旧業務照合、再開承認、未処理案件の回収
exitデータ返却・削除、移行支援代替先、アカウント停止、残存リスク確認

モデル提供者、AIアプリベンダー、クラウド、導入会社、現地法人、本社が複数いる場合は、一社に丸を付けず、サービス層ごとに分けます。契約上の責任と、現場で実際に操作できる権限が一致するかも確認します。夜勤に出力を止められる人がいないなら、手順書に停止責任者を書くだけでは統制になりません。

human-in-commandを画面・権限・時間へ落とす

人の監督は「最終判断は人」と書けば完了するものではありません。人が大量の出力を追認するだけなら、実質的な介入になりません。用途ごとに次を定義します。

  1. 見えること:入力元、出力、信頼の限界、参照根拠、モデル・設定版、警告を表示する。
  2. 理解できること:現地の利用者が理解できる言語と業務語で説明する。
  3. 拒否できること:拒否、修正、保留、上位承認への送付を権限として持つ。
  4. 止められること:利用者、班長、IT、経営のどの層が何を停止できるか決める。
  5. 代替できること:停止後に紙、既存画面、人手判断へ戻せる。
  6. 学習できること:拒否理由を改善へ回すが、個人データや機密を無制限に再利用しない。

製造現場では応答時間も重要です。設備異常の参考情報と、月次報告の要約では許容時間が違います。「人が確認する」ではなく、確認期限、期限超過時の扱い、無応答時の安全側動作を決めます。自動実行へ進む場合は、承認の前後で何が変化し、取り消し可能な時点がどこかを試験します。

ベトナム AI開発のRFPを採点可能な要求へ変える

良いRFPは機能一覧ではなく、ベンダー回答を同じ物差しで比較し、そのままPoCへ渡せる文書です。以下は提案値です。各社のリスク許容度に合わせて重みを変更してください。

評価領域提案配点ベンダーに求める回答PoCで見る証拠
用途・分類15分類、前提、Decision 33確認、変更条件版付き分類票、再分類デモ
データ保護15全フロー、保持、再利用、越境、終了設定、通信・操作ログ、削除試験
業務品質15正常・拒否・曖昧・未知への挙動固定評価セットと誤り分析
human-in-command15表示、承認、拒否、停止、代替役割別シナリオと停止証跡
セキュリティ10ID、権限、暗号、脆弱性、事故対応権限外拒否、監査ログ、復旧
統合・変更10API、版、依存先、目的変更、通知変更前後の影響・再試験
運用・現地支援10言語、時間帯、SLA、教育、保守ベトナム現場での対応訓練
出口性10データ返却、削除、移行、停止費用エクスポート、削除、ロールバック

配点だけでなく、失格条件を先に決めます。たとえば「顧客データの再利用条件を回答できない」「停止権限を提供できない」「分類対象版を特定できない」「ログを顧客が取得できない」は、総合点が高くても次へ進めない条件にできます。これらは法定の一律条件ではなく、調達者が定める提案例です。

回答欄は「対応可/不可」で終わらせません。標準、設定、個別開発、外部製品、将来計画を分け、前提、制限、責任者、証拠、変更時の影響を記入させます。ベンダーデモには自社の代表データだけでなく、空欄、矛盾、権限外、プロンプトインジェクションを疑う入力、機密混入、未知の質問を含めます。

AI製品の比較軸を先に整理する場合は生成AIツール選定2026を、本社と複数拠点の役割設計は海外拠点の生成AI導入ロードマップを参照してください。本稿は、その一般枠をベトナムの2026年制度と発注・受入証跡へ具体化する位置付けです。開発委託の体制・成果物を比較する観点はタイのAI開発委託ガイドも応用できます。

ベトナム AI 導入2026|AI法対応RFPと90日PoC設計 - figure 2

90日PoC例|精度以外を受入ゲートにする

次の90日は提案例です。用途の複雑さ、データ準備、法務確認、工場カレンダーに応じて調整してください。目的は90日で本番化することではなく、継続・条件付き継続・再設計・停止を証拠で決めることです。

Day 0–20:用途、分類、データ契約を固定

ユースケースカード、現行フロー、誤り影響、利用者、データフローを確定します。providerの分類票を受領し、Decision 33該当性をベトナムの専門家へ確認するための事実資料を整えます。Personal Data LawとDecree 356の適用は法務・DPOが確認し、PoC環境へ持ち込めるデータ、マスキング、アクセス、保持、越境、削除を承認します。

この段階のゲート例は「対象用途・版・利用者が一意に特定できる」「未確認のデータ経路がない」「業務、IT、法務・プライバシー、セキュリティの判定者が決まった」です。未達なら、モデル接続を急がず範囲を縮小します。

Day 21–45:品質、拒否、権限、漏えい耐性を試す

代表ケースだけでなく、難例、欠損、矛盾、古い文書、対象外質問を固定評価セットにします。正答率だけでなく、答えるべきでないときに拒否できるか、根拠がないと明示できるか、権限外文書を検索しないか、別利用者の履歴を露出しないかを確認します。

評価値は用途別に自社で設定します。提案例として、重大な機密露出と権限越境は受入件数0、重大判断は必ず指定役割の承認を通る、根拠不明の回答は自動実行へ渡さない、といった絶対条件を置きます。平均精度が高くても絶対条件に違反すればゲートを通しません。

Day 46–70:人の介入、停止、障害、再分類を試す

現地の利用者がベトナム語または必要な業務言語で、警告、根拠、版、拒否操作を理解できるか確認します。モデルAPI遅延、停止、ログ欠落、ID連携障害、誤設定、データ更新失敗を注入し、代替業務へ切り替えます。

さらに、RAGへ新しい文書群を追加する、別工程へ用途を広げる、モデル版を変える、出力をERP/MESの更新候補へ接続する、利用者を外部委託先へ広げる、という変更シナリオを一つずつ試します。分類やデータフローに影響する場合、変更申請が再分類レビューを起動し、承認前には本番反映されないことを証拠化します。

Day 71–90:出口、ロールバック、受入委員会

設定、プロンプト、評価セット、ログ、ユーザー、接続先、残存データを一覧化します。サービスを停止し、旧手順へ戻し、未処理案件を照合し、必要データをエクスポートし、契約上の削除手順を試します。単にバックアップを戻すのではなく、AI出力を受けて進行した業務をどの時点へ戻せるかを確認します。

最終判定は提案例として、①限定本番、②条件付き延長、③再設計、④停止の四つにします。営業担当ではなく、業務オーナー、現地経営、IT、セキュリティ、法務・プライバシーが証拠パックを確認し、未解決事項の責任者と期限を記録します。

受入証跡パックに残すもの

受入は会議の議事録だけでは足りません。後から「どの版を、どの用途で、誰が、何を見て承認したか」を再現できる必要があります。

  1. ユースケースID、要件ID、テストID、リスク・データ項目の対応表。
  2. providerの分類票、顧客側用途カード、Decision 33確認の依頼資料と専門家回答。
  3. モデル、アプリ、プロンプト、RAG、フィルタ、権限、接続先の版。
  4. 評価セットの由来、機密区分、期待結果、実績、評価者、差異理由。
  5. 正常回答だけでなく、拒否、保留、権限外、漏えい防止、人の介入の記録。
  6. 変更申請、再分類レビュー、承認、展開、再試験、ロールバックの履歴。
  7. 障害の検知、停止、連絡、代替業務、復旧、業務照合、再開承認。
  8. 個人データ・機密データの保管、閲覧、越境、評価利用、返却・削除の証跡。
  9. ベンダー、クラウド、モデル提供者、再委託先の契約版と通知記録。
  10. 未解決リスク、暫定策、期限、所有者、残存リスクを受け入れた承認者。

証拠には時刻と版を持たせます。スクリーンショットだけでは設定全体や改変履歴を示せない場合があるため、設定エクスポート、監査ログ、テスト結果、承認ワークフローを組み合わせます。ログ自体が個人データや機密を含む可能性もあるため、証拠保全とアクセス制御を両立させます。

ベトナム AI 導入2026|AI法対応RFPと90日PoC設計 - figure 3

変更時再分類を本番運用のゲートにする

AIは導入時の状態で固定されません。モデル、プロンプト、RAG文書、API、利用者、言語、利用目的、出力の接続先、providerの再委託先が変わります。変更を一般的なIT変更だけで処理すると、リスク分類やデータフローへの影響を見落とします。

変更申請には次の質問を必須にします。

  • 想定用途、利用者、影響を受ける人、出力の使い方は変わるか。
  • 新しい個人データ、機密、画像、音声、ログ、評価データを扱うか。
  • 保存場所、越境、再委託、モデルの再利用条件は変わるか。
  • 人の確認、停止権限、代替業務、応答期限は変わるか。
  • 既存の分類前提やDecision 33確認結果へ影響するか。
  • どの評価セットを再実行し、どの絶対条件を満たす必要があるか。
  • 問題時にどの版へ戻し、進行中業務をどう照合するか。

小さなUI変更と、目的・統合が変わる変更を同じ承認経路にする必要はありません。事前にトリガーを決め、自動的に法務・プライバシー・セキュリティへ回る変更と、通常運用で閉じる変更を分けます。ただし「モデルの自動更新だから変更ではない」と扱わず、providerの通知、版の可視性、回帰試験、停止猶予を契約で確認します。

AI導入 進め方で起きる失敗と防止策

法務確認を契約直前に置く

製品を決めた後に確認すると、データ経路や責任境界を変えられません。用途カードとフロー図をRFP前に作り、専門家が具体的事実を確認できるようにします。

ベンダーの分類結果を用途全体へ流用する

モデル単体の想定と、現場統合後の使い方は異なります。分類対象、版、用途、利用者、統合先を一組で管理します。

精度の平均だけでPoCを合格にする

平均値は、機密露出、権限越境、危険な自信過剰、停止不能を隠します。拒否、権限、漏えい、人の介入、再分類、出口を独立ゲートにします。

human-in-the-loopを承認ボタンで済ませる

判断材料が見えず、時間も権限もなければ、承認は形式化します。表示、理解、拒否、停止、代替、エスカレーションを現地シフトで試します。

PoC専用のきれいなデータだけを使う

本番では古い文書、矛盾、権限差、ベトナム語と英語の混在、画像品質のばらつきがあります。保護した本番相当データと難例を評価セットへ入れます。

終了条件を更新契約時まで決めない

データ、プロンプト、評価セット、埋め込み、ログ、設定を取り出せるか、削除をどう確認するか、代替業務へ戻せるかをPoCで試します。

東南アジア AI 活用へ横展開するときの境界

ベトナムで作った統制をタイ、シンガポール、インドネシアなどへ展開する場合、画面と言語だけを複製してはいけません。用途、分類、個人データ、越境、労務、契約、現地サポートは国・法人・業務で再確認します。一方で、ユースケースID、評価セットの作り方、変更トリガー、証拠パック、停止訓練の型は共通化できます。

本社が持つべきものは、承認をすべて中央へ集める権限ではなく、比較可能な最小基準です。現地法人は実用途、利用者、言語、業務影響、代替手順を所有し、本社はモデル・クラウド契約、共通セキュリティ、監査、複数国の知見を支えます。providerの分類と現地専門家の法的確認を、グローバル標準のチェック欄だけで置き換えないことが重要です。

実行チェックリスト

RFP発行前

  • [ ] 用途を判断単位へ分解し、業務・データ・システム・リスクの所有者を置いた。
  • [ ] AI Law、Decree 142、Decision 33の確認に必要な事実資料を作った。
  • [ ] 入力、ログ、評価、保守、バックアップ、越境、終了のデータフローを描いた。
  • [ ] provider/deployer/クラウド/導入会社/本社/現地法人の責任を動詞で分けた。
  • [ ] 人が見る情報、拒否、停止、代替、エスカレーションを用途別に決めた。
  • [ ] 変更時再分類のトリガーと、専門家確認の責任者を決めた。

PoC開始前

  • [ ] 分類対象の製品・モデル・アプリ・設定版を固定した。
  • [ ] 評価セットの由来、期待結果、機密区分、アクセス権を承認した。
  • [ ] 精度以外に拒否、権限、漏えい、人の介入、障害、出口のゲートを置いた。
  • [ ] 現地利用者が理解できる言語で画面、警告、教育、連絡経路を用意した。
  • [ ] 失敗時にPoCを停止し、データとアカウントを回収する手順を試せる。

本番判定前

  • [ ] 受入証跡から要件、版、テスト、承認を追跡できる。
  • [ ] 未解決事項に重大度、暫定策、期限、責任者、残存リスク承認がある。
  • [ ] 変更申請が再分類、データ、セキュリティ、回帰試験へ連動する。
  • [ ] provider障害・契約終了・モデル変更時に停止、代替、ロールバックできる。
  • [ ] ベトナムの専門家が最新法令本文と具体的用途の適用関係を確認した。

まとめ|ベトナム AI 導入は「買う前の証拠設計」で決まる

ベトナムでAIを導入する際は、最新法令を後付けの確認表にせず、用途、分類、Decision 33確認、個人データと越境、責任境界、人の介入、変更時再分類、証跡と出口を一枚のRFPへ統合してください。90日PoCは提案例ですが、精度だけでなく、拒否、権限、情報漏えい、人の介入、再分類トリガー、停止、ロールバックを受入ゲートにする考え方は、製品や用途が変わっても使えます。法的結論はベトナムの専門家へ確認し、企業側は判断材料と運用証拠を継続的に整えることが重要です。

ベトナム工場・現地法人でのユースケース整理、AI対応RFP、PoC受入設計を検討段階から具体化したい場合は、TOMAS TECHへお問い合わせください。製品が未定の段階でも、業務・データ・統制の境界整理から相談できます。

FAQ|ベトナム AI開発は何から始めるべきですか?

製品選定ではなく、ユースケース棚卸しから始めます。利用者、入力、出力、判断への影響、誤りの影響、データフロー、停止方法を一枚にし、providerの分類と専門家による適用確認に必要な事実をそろえます。その後にRFPを発行すると、ベンダー回答を同じ条件で比較できます。

FAQ|海外拠点 生成AI 導入で本社と現地はどう分担しますか?

本社は共通のセキュリティ、契約、評価・証跡の型を提供し、現地は実用途、利用者、言語、業務影響、代替手順を所有する形が実務的です。法的な適用判断を本社標準だけで代替せず、ベトナムの専門家確認を組み込みます。

FAQ|東南アジア AI 活用へ同じ仕組みを展開できますか?

ユースケースID、評価セット、変更トリガー、証拠パックの型は共通化できます。ただし、分類、個人データ、越境、契約、労務、現地運用は国・法人・用途ごとに再確認が必要です。ベトナムでの結論を他国へそのまま移さないでください。

FAQ|AI導入 進め方として90日PoCは必須ですか?

必須ではありません。本稿の90日は提案例です。重要なのは期間ではなく、精度、拒否、権限、漏えい、人の介入、変更時再分類、障害、出口を合否ゲートとして事前に決めることです。低リスクで単純な用途なら短縮し、データや統合が複雑なら延長します。

注意事項

本稿は2026年9月7日時点で確認した一次情報を、AI調達と実装管理の観点から整理したもので、法的助言ではありません。法令の原文、適用範囲、要求事項、経過措置、当局運用は、ベトナムの有資格専門家および社内法務・プライバシー・セキュリティ担当へ確認してください。本文中のRFP配点、失格条件、90日工程、受入値はすべて提案値・例示です。

参考情報