AI Migration là gì? Có thể migrate AI như migrate cloud không?

Doanh nghiệp đang đưa AI vào sử dụng nhanh hơn tốc độ ghi chép cách các hệ thống đó vận hành. Một team có thể bắt đầu với API model, rồi bổ sung prompt, retrieval, memory, connector, scheduled job và bước phê duyệt cho đến khi tác vụ có AI hỗ trợ trở thành một phần của hoạt động hằng ngày.

Bàn giao thủ công mới chỉ là điểm bắt đầu

Ở cấp độ cá nhân, nhiều người đã thực hiện một dạng AI migration sơ khai: xuất lịch sử hội thoại, tóm tắt ngữ cảnh, viết file bàn giao hoặc SKILL.md, rồi chuyển phần tài liệu đó sang một AI khác. Nếu hệ thống mới có thể tiếp tục công việc và làm theo quy trình cũ, ta dễ có cảm giác như AI đã được chuyển sang.

Nhưng thực sự điều gì đã được chuyển? Tài liệu bàn giao có thể mang theo ngữ cảnh đã được ghi lại, còn skill có thể đóng gói một quy trình. Không thứ nào tự động chuyển được memory gốc của nền tảng, trạng thái phiên đang chạy, quyền dùng công cụ, cấu hình connector, tác vụ đã lên lịch, lịch sử audit hay hành vi được định hình bởi model và runtime ban đầu.

Với doanh nghiệp, câu hỏi rộng hơn: nếu AI đã trở thành một phần của quy trình vận hành, tổ chức có thể chủ động chuyển nó như cách đã chuyển ứng dụng, cơ sở dữ liệu và hạ tầng không? Có, nhưng đối tượng cần chuyển không chỉ là một model. Đó là workload tạo ra kết quả.

Những gì thực sự được migrate là gì?

Cloud migration thường chuyển các thành phần ứng dụng, dữ liệu và hạ tầng. AI migration còn phải giữ lại hoặc chủ động tái tạo hành vi trong những ràng buộc cụ thể. Hành vi của workload AI không có checksum để đối chiếu: hệ thống đích phải vượt qua bước đánh giá và được nghiệp vụ chấp nhận, chứ không chỉ nhận các file đã sao chép.

Đơn vị cần migrate có thể là model endpoint, tính năng AI, ứng dụng RAG (retrieval-augmented generation), agent, workflow nhiều agent, automation chạy theo lịch hoặc cách một team làm việc với AI. Gọi tất cả những thứ này là “model” sẽ che khuất các dependency có thể quyết định việc thay đổi có an toàn hay không.

Migrate model

Đây là phạm vi hẹp nhất: thay một model hoặc endpoint trong khi phần lớn ứng dụng và workflow được giữ nguyên. Ngay cả khi đó, khả năng làm theo chỉ dẫn, gọi công cụ, xuất dữ liệu có cấu trúc, xử lý ngữ cảnh, hành vi an toàn, latency và chi phí vẫn có thể thay đổi. API có cấu trúc tương tự không đảm bảo hành vi tương đương.

Migrate ứng dụng AI

Chuyển chatbot, hệ thống RAG, pipeline xử lý tài liệu hoặc một tính năng AI cần nhiều hơn việc thay model. Embedding, vector index, logic retrieval, prompt template, bộ lọc, logging, quy tắc lưu trú dữ liệu và tích hợp với ứng dụng hiện tại đều có thể cần được điều chỉnh.

Migrate agent

Một agent có thể đọc dữ liệu, chọn hành động, gọi công cụ, ghi vào hệ thống nghiệp vụ và chờ con người phê duyệt. Vì vậy phạm vi migration gồm instruction và skill, công cụ và API contract, danh tính và quyền hạn, tri thức và retrieval, memory ngắn hạn lẫn dài hạn, trạng thái workflow, tác vụ theo lịch, điểm phê duyệt, audit trail, xử lý lỗi và tính idempotent.

Ngữ cảnh vận hành giữa con người và AI

Theo thời gian, một team hình thành cách làm việc với AI: lịch sử quyết định, kỳ vọng về chất lượng, các trường hợp ngoại lệ, thói quen rà soát và phạm vi quyền được giao. Một phần ngữ cảnh này được ghi lại; phần khác nằm trong memory của nền tảng hoặc thói quen làm việc của một nhân viên. Vì vậy, thay đổi nền tảng có thể tác động đến cách tổ chức vận hành, chứ không chỉ đến dữ liệu.

Interoperability không đồng nghĩa với migration

MCP, A2A và Agent Skills cung cấp những khối xây dựng hữu ích, nhưng mỗi thứ giải quyết một ranh giới khác nhau. Interoperability là khả năng các hệ thống giao tiếp với nhau. Portability là khả năng một năng lực chạy ở nơi khác sau những điều chỉnh có thể chấp nhận được. Migration còn đòi hỏi discovery, điều chỉnh, kiểm chứng, cutover, rollback và vận hành sau cutover.

MCP: kết nối công cụ và tài nguyên nhất quán hơn

Model Context Protocol chuẩn hóa cách một ứng dụng AI kết nối với công cụ và tài nguyên thông qua host, client và server. Khi ranh giới công cụ ổn định, điều này có thể giảm phần tích hợp riêng phải xây dựng. Tuy nhiên, bản thân MCP không chuyển memory của agent, chính sách nghiệp vụ, trạng thái workflow, baseline đánh giá hay hành vi đặc thù của từng nhà cung cấp. Nguồn: https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture

A2A: agent có thể phối hợp mà không trở nên portable

Giao thức Agent2Agent là một tiêu chuẩn mở để các hệ thống agent độc lập giao tiếp với nhau. A2A có thể hỗ trợ phối hợp giữa các cách triển khai khác nhau; giao thức này không làm lộ hoặc chuyển toàn bộ memory nội bộ, công cụ, quyền hạn hay logic độc quyền của từng agent. Agent giao tiếp được với nhau không có nghĩa là một agent đã được migrate. Nguồn: https://a2a-protocol.org/latest/topics/what-is-a2a/

Agent Skills: quy trình tái sử dụng vẫn cần kiểm tra runtime

Skill có thể đóng gói instruction, script và tài nguyên hỗ trợ rõ ràng hơn một prompt dài. Nhưng skill vẫn có thể phụ thuộc vào extension của runtime, công cụ sẵn có, mô hình phân quyền và cách từng model diễn giải. Hãy xem skill là một thành phần cần kiểm thử khi migration, không phải bằng chứng rằng toàn bộ workload có thể portable. Nguồn: https://docs.anthropic.com/en/docs/claude-code/skills

Có thể phân biệt các khái niệm như sau: interoperability là khả năng giao tiếp; portability là khả năng chạy ở nơi khác với những thay đổi chấp nhận được; migration là quy trình có kiểm soát để chuyển và kiểm chứng workload từ đầu đến cuối.

Một framework thực tế cho AI migration

Thực tiễn cloud migration là một điểm đối chiếu hữu ích, không phải playbook AI có thể áp dụng nguyên xi. AWS mô tả bảy chiến lược chuyển ứng dụng lên cloud: Retire, Retain, Rehost, Relocate, Repurchase, Replatform và Refactor hoặc Re-architect. Workload AI cần những lựa chọn riêng vì hành vi, quyền truy cập dữ liệu, công cụ và kiểm soát vận hành cũng là những thứ phải được duy trì. Nguồn: https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html

1. Khám phá workload và các dependency

Bắt đầu từ tác vụ nghiệp vụ, không phải tên model. Xác định kết quả cần đạt, người phụ trách, người dùng, đầu vào, đầu ra và các hệ thống downstream. Sau đó lập inventory model và version, prompt, skill, kho tri thức, vector index, công cụ, connector, danh tính, quyền hạn, job theo lịch, trạng thái workflow, bộ đánh giá, telemetry và các luồng xử lý lỗi. Dependency nào chưa giải thích được là rủi ro migration, không phải chi tiết có thể để sau.

2. Lập bản đồ ranh giới hiện trạng

Ghi lại nguồn dữ liệu và chiều luân chuyển, ranh giới đọc/ghi, danh tính được mỗi hành động sử dụng, các điểm cần con người phê duyệt, kho lưu trạng thái, bằng chứng audit, năng lực đặc thù của nhà cung cấp và đường rollback. Đối chiếu cấu hình với runtime log: trong mã nguồn có thể có tích hợp không còn dùng, trong khi connector của nền tảng có thể không xuất hiện trong repository.

3. Thiết lập baseline hành vi

Xây dựng bộ đánh giá đại diện trước khi thay đổi hệ thống nguồn. Bao gồm tình huống thông thường, thông tin thiếu hoặc mâu thuẫn, yêu cầu không an toàn, lỗi quyền hạn, lỗi từ nhà cung cấp, hành động trùng lặp và trường hợp cần con người rà soát. Behavioral parity không phải là sự giống hệt đầu ra theo từng byte: các model khác nhau có thể dùng câu chữ khác nhau nhưng vẫn bảo toàn hành vi, ràng buộc và kết quả quan trọng. Tách deterministic checks khỏi đánh giá semantic hoặc probabilistic. Deterministic checks bao gồm tính hợp lệ của schema, tuân thủ structured output, tính đúng đắn của function/tool contract, trường bắt buộc, authorization, hành động bị cấm, ràng buộc side effect, cùng trần latency hoặc reliability khi phù hợp. Đánh giá semantic bao gồm task success, groundedness, answer relevance, domain correctness, safety behavior, policy adherence, retrieval quality và behavioral consistency. Kết hợp deterministic assertions, đánh giá dựa trên tham chiếu, metric theo tác vụ, semantic similarity khi phù hợp, human review và model-based grader đã được hiệu chỉnh. Model-based grader cần được calibration với human judgment. Ghi baseline, acceptance gate và evidence vào AWMM; workload đích chỉ được chấp nhận khi vượt qua các gate đã thống nhất, không phải đơn giản vì output trông hợp lý.

Tách deterministic check khỏi đánh giá ngữ nghĩa hoặc xác suất. Deterministic check bao gồm tính hợp lệ của schema, tuân thủ structured output, tính đúng đắn của function và tool contract, trường bắt buộc, ủy quyền, hành động bị cấm, ràng buộc side effect, cùng ngưỡng latency hoặc độ tin cậy khi phù hợp.

Đánh giá ngữ nghĩa bao gồm mức độ hoàn thành tác vụ, groundedness, mức độ phù hợp của câu trả lời, tính đúng đắn theo miền, hành vi an toàn, tuân thủ policy, chất lượng retrieval và tính nhất quán hành vi. Hãy dùng deterministic assertion, đánh giá dựa trên tham chiếu, metric theo tác vụ, semantic similarity khi phù hợp, human review và model-based grader đã được hiệu chỉnh. Model-based grader có thể hữu ích nhưng phải được hiệu chỉnh theo đánh giá của con người.

Ghi nhận baseline, acceptance gate và bằng chứng trong AWMM; hệ thống đích chỉ được chấp nhận khi vượt qua các gate đã thống nhất, không chỉ vì output trông có vẻ hợp lý. Về bối cảnh governance, NIST AI RMF 1.0 tổ chức công việc quản trị rủi ro theo Govern, Map, Measure và Manage. Đây là khung quản trị rủi ro, không phải khung AI migration; vì vậy hãy dùng nó để định hướng governance và evaluation thay vì coi đây là phương pháp migration. Nguồn: NIST AI RMF Core, Hình 5.

4. Đưa các tài sản cần duy trì ra khỏi runtime

Đưa instruction quan trọng vào file có version, xác định tool contract, lưu tri thức trong kho được quản trị, mô tả memory bằng schema tường minh, biểu diễn workflow dưới dạng state machine khi phù hợp và duy trì bộ đánh giá có thể chạy lặp lại. Lưu secret trong secrets manager và chỉ ghi lại tham chiếu. SKILL.md có thể đóng gói quy trình, nhưng không thể thay thế danh tính, bản đồ dependency, quyền hạn, trạng thái, đánh giá hay bằng chứng.

Một portability package được đề xuất có thể gồm manifest, instruction, skill, định nghĩa workflow, tool contract, manifest tri thức và memory, policy, bộ đánh giá, ánh xạ từ nguồn sang đích và kế hoạch rollback. Đây là đề xuất kiến trúc của TitanBases, không phải tiêu chuẩn ngành.

5. Chuẩn bị môi trường đích trước khi chuyển workload

AI landing zone là một phép so sánh hữu ích để hình dung các kiểm soát cần có trước khi tiếp nhận workload: danh tính workload, quyền công cụ tối thiểu cần thiết, quản lý secret, ranh giới tri thức, version của prompt và skill, logging và tracing, đánh giá, phân bổ chi phí, con người phê duyệt, chính sách lưu giữ, xử lý sự cố, fallback và rollback. Đây cũng là một khái niệm kiến trúc được đề xuất, không phải tiêu chuẩn chính thức. Không chuyển agent sang runtime mới cho đến khi môi trường đích kiểm soát được agent có thể đọc, ghi và ủy quyền những gì.

Theo góc nhìn kiến trúc thực tế của TitanBases, có bốn control plane quan trọng: Identity & Policy (danh tính workload, ủy quyền người dùng/dịch vụ, quyền hạn và thực thi policy); Model & Orchestration (routing model, model gateway, orchestration và runtime control); Context & Data (RAG, memory, retrieval, ranh giới dữ liệu và provenance); và Operations & Assurance (observability, evaluation, guardrail, xử lý sự cố, kiểm soát chi phí và audit).

Trước khi workload đến, hãy thiết lập model gateway hoặc lớp routing; quyền truy cập công cụ theo least privilege; secret management; ranh giới tri thức; versioning prompt và skill; logging và tracing; evaluation; phân bổ chi phí; phê duyệt bởi con người; retention; xử lý sự cố; fallback và rollback; danh mục model/nhà cung cấp được phê duyệt; và thực thi policy.

Đây là khái niệm kiến trúc do TitanBases đề xuất, không phải tiêu chuẩn chính thức. Không nên chuyển một agent vào runtime nếu hệ thống đích chưa kiểm soát được agent có thể đọc, ghi và ủy quyền những gì. Nếu không, tổ chức có thể đổi vendor lock-in lấy rủi ro vận hành.

6. Chọn chiến lược cho từng workload

Một cách phân loại thực tiễn do TitanBases đề xuất có thể giúp định hướng quyết định: retain workload chưa có đích đến an toàn hoặc hợp lý; retire workload không còn tạo giá trị; repoint ứng dụng sang model endpoint khác; rebind agent với công cụ, danh tính và tri thức mới; replatform sang runtime được quản lý khác; reconstruct memory, skill hoặc kiểm soát không thể chuyển nguyên trạng; hoặc re-architect để giảm coupling không cần thiết. Đây là bộ thuật ngữ làm việc được đề xuất, không phải tiêu chuẩn migration chính thức. Một danh mục workload có thể đồng thời áp dụng nhiều cách tiếp cận.

7. Chuyển theo từng đợt, từ ít rủi ro đến có trạng thái

Một trình tự hợp lý là bắt đầu với tác vụ tóm tắt, phân loại, soạn thảo hoặc trích xuất không lưu memory và không có công cụ ghi dữ liệu. Tiếp theo là RAG hoặc tìm kiếm dựa trên tri thức; cần kiểm chứng chất lượng retrieval, trích dẫn, kiểm soát truy cập và độ mới của index. Sau đó mới chuyển agent dùng công cụ với kiểm tra quyền rõ ràng và bước phê duyệt của con người. Để agent có trạng thái hoặc chạy theo lịch về cuối, sau khi đã diễn tập snapshot trạng thái, idempotency, xử lý tác vụ đang chờ và rollback.

8. Xử lý memory và trạng thái vận hành như hai luồng riêng

Phân loại ngữ cảnh trước khi chuyển. Tri thức, sở thích người dùng, dữ kiện nghiệp vụ, quyết định trong quá khứ, memory theo sự kiện và bằng chứng có chủ sở hữu, mức độ nhạy cảm và quy tắc lưu giữ khác nhau. Trạng thái vận hành lại là một vấn đề khác: phê duyệt đang chờ, trạng thái tác vụ, cursor, số lần retry và idempotency key cần lấy từ system of record, không nên tái tạo từ bản tóm tắt hội thoại. Kiểm tra lại độ mới và quy tắc truy cập ở hệ thống đích; đừng xuất hàng loạt hội thoại hay dữ liệu khách hàng chỉ để phòng xa.

Di chuyển RAG hoặc memory dựa trên vector không chỉ là sao chép vector. Thay đổi về embedding model hoặc số chiều, chunking, normalization, metadata schema, namespace hoặc ranh giới tenant, cấu hình index, similarity metric, hybrid search, reranking, provenance của tài liệu nguồn và policy retention hoặc deletion có thể khiến cần re-embedding.

Kiểm tra data portability (có thể export tài liệu, bản ghi memory và metadata không?), representation portability (hệ thống đích có thể dùng cùng representation không?), và behavioral portability (retrieval có còn trả về bằng chứng tương đương đủ tốt không?). Chạy retrieval regression test cho recall và relevance trên truy vấn đã biết, truy xuất tài liệu quan trọng, tính chính xác của citation và nguồn, ranh giới tenant và quyền hạn, latency và failure case. Trong AWMM, ghi nhận chúng như asset, transformation, baseline, acceptance gate và bằng chứng. Index được sao chép không phải bằng chứng về behavioral equivalence.

Đối với agent có khả năng ghi, runtime rollback không tự động đảo ngược side effect bên ngoài: thao tác ghi cơ sở dữ liệu, thay đổi CRM, ticket, provisioning, email, thao tác tài chính và gọi API bên thứ ba cần operation identifier hoặc idempotency key ổn định, trạng thái thao tác bền vững và đôi khi là hành động bù trừ.

Trước cutover, hãy hoàn tất, chuyển giao, đối soát hoặc chủ động hủy các thao tác ghi đang chờ, action trong hàng đợi, lần thực thi chưa xử lý, scheduled job, side effect bên ngoài và workflow mới hoàn thành một phần. Trạng thái chưa rõ hoặc rủi ro cao phải được chuyển sang xử lý ngoại lệ bởi con người thay vì phỏng đoán.

9. Chạy lại và so sánh trước cutover

Chạy hệ thống đích trên bộ đánh giá đã được phê duyệt. Khi an toàn, có thể dùng shadow traffic hoặc chạy song song nhưng không để phát sinh thao tác ghi trùng. So sánh kết quả nghiệp vụ, chất lượng bằng chứng, quyền hạn, hành vi an toàn, lựa chọn công cụ, xử lý lỗi, latency và chi phí. Điều tra các điểm suy giảm thay vì che chúng trong một điểm tổng hợp. Giữ bước con người rà soát cho những hành động có mức rủi ro yêu cầu.

10. Cutover với khoảng thời gian rollback

Xác định rõ người phụ trách cutover, kế hoạch đóng băng hoặc đối soát trạng thái, phạm vi canary, ngưỡng thành công, thời gian theo dõi và điều kiện kích hoạt rollback. Ngăn cả hai hệ thống thực hiện cùng một tác động phụ. Giữ log và trạng thái của hệ thống nguồn cho đến khi đích được chấp nhận. Kế hoạch chuyển ngược chỉ thực sự là rollback khi dữ liệu và công việc đang chờ có thể được đối soát an toàn.

11. Vận hành và tiếp tục đánh giá

Sau cutover, theo dõi sai lệch chất lượng, lỗi công cụ, từ chối quyền, thao tác ghi đè của con người, latency, lượng token và chi phí trên mỗi kết quả thành công. Duy trì lịch sử version của model, instruction, skill, policy, công cụ và bộ đánh giá. Migration chỉ kết thúc khi hệ thống đích được chấp nhận và có thể vận hành, không phải khi endpoint cũ ngừng nhận traffic.

Những gì team có thể chuẩn bị trước khi có lịch migration

Phần lớn tổ chức sẽ chưa lên kế hoạch AI migration khi mọi workflow vẫn có vẻ hoạt động bình thường. Nhưng prompt dần trở thành business logic, memory của nền tảng thành dependency không được ghi nhận, còn connector được cấp quyền trước cả khi dự án migration chính thức bắt đầu. Việc chuẩn bị nên bắt đầu từ những người đang xây dựng và dùng AI hôm nay, không chỉ từ kiến trúc sư sau khi có thông báo đổi nhà cung cấp.

Hãy xem xét một agent hỗ trợ khách hàng doanh nghiệp có trạng thái được chuyển từ Runtime A sang Runtime B. Workload gồm instruction cốt lõi; Agent Skills hoặc asset quy trình tương đương; công cụ kết nối MCP; tri thức dựa trên vector; memory hội thoại và tác vụ bền vững; quyền ghi CRM; lịch follow-up; danh tính doanh nghiệp; observability; và một bộ evaluation. Đây là ví dụ kiến trúc minh họa, không phải case của khách hàng TitanBases.

Cách xử lý migration: instruction cốt lõi có thể portable nhưng cần validation; skill có thể portable khi được hỗ trợ; binding công cụ MCP phải được bind lại và contract-test; vector index có thể cần build lại hoặc re-embedding khi representation thay đổi; durable memory phải được transform và validation; quyền hạn cần remap rõ ràng và review theo least privilege; scheduled job phải được dựng lại hoặc chuyển giao an toàn; thao tác ghi đang chờ phải được đối soát trước cutover; bộ evaluation được giữ làm baseline; trạng thái đặc thù runtime được transform, dựng lại hoặc loại bỏ.

Acceptance gate minh họa — không phải ngưỡng phổ quát — gồm: tỷ lệ pass của critical scenario đã duyệt đạt baseline; các tool-contract test bắt buộc đều pass; không có mở rộng quyền hạn trái phép; các scenario retrieval và memory quan trọng đều pass; không còn side effect trùng lặp chưa xử lý; và quy trình rollback thành công trong bài kiểm thử có kiểm soát. Mục đích là giúp việc nghiệm thu có thể review, không phải khẳng định một điểm số phổ quát.

Xây dựng AI Workload Readiness Pack

Bản dump hội thoại, HANDOFF.md hoặc SKILL.md có thể giữ lại một phần ngữ cảnh hay quy trình. Không tài liệu nào trong số đó đại diện cho toàn bộ workload. Có thể duy trì gói khởi đầu hữu ích bằng tài liệu và bảng tính thông thường; không bắt buộc phải dùng đúng định dạng file cụ thể. Tối thiểu, gói này cần một bản ghi đã được chủ sở hữu xác nhận về workload làm gì, cần hành xử ra sao, phụ thuộc vào đâu, có thể truy cập những gì, thành công được đánh giá thế nào và được vận hành ra sao.

Nội dung gợi ý: 00-workload-card.md; 01-behavior-and-policy.md; 02-dependencies.yaml; 03-knowledge-memory-register.csv; 04-tool-permission-matrix.csv; 05-evals.jsonl; 06-runbook.md; skills/; state/; CHANGELOG.md. Bổ sung MEMORY-REGISTER.csv và STATE-SCHEMA.md nếu workload có memory dài hạn hoặc workflow đang hoạt động. Đây là tên gọi ví dụ, không phải định dạng bắt buộc.

• WORKLOAD.md — mục đích, chủ sở hữu nghiệp vụ và kỹ thuật, người dùng và kết quả kỳ vọng.
• BEHAVIOR.md — hành vi được phép, bị cấm và cần phê duyệt.
• DEPENDENCIES.yaml — model, dữ liệu, công cụ, connector, lịch chạy và giả định runtime.
• ACCESS-MATRIX.csv — danh tính, quyền hạn, điểm phê duyệt và side effect có thể xảy ra.
• EVALS.jsonl — các case đại diện, kết quả kỳ vọng và điều kiện pass/fail.
• RUNBOOK.md — cách vận hành, tạm dừng, khôi phục, fallback và rollback.

Để tạo các tài liệu này, hãy phỏng vấn chủ sở hữu nghiệp vụ và kỹ thuật về kết quả, người dùng và tác động khi có lỗi; trích xuất instruction và quy tắc từ prompt, policy đã duyệt, ticket và phần con người chỉnh sửa; kiểm tra repository, cấu hình, connector, bộ lập lịch và runtime log để tìm dependency; lập inventory các kho tri thức và memory thực tế; xác minh quyền từ IAM, OAuth scope, cấu hình connector và audit log; xây dựng tình huống đánh giá từ công việc thành công, sự cố và đầu ra bị từ chối; đồng thời ghi lại cách vận hành cùng những người thực sự tạm dừng, tiếp tục và khôi phục workload.

• Workload card — phỏng vấn chủ sở hữu nghiệp vụ và kỹ thuật, người dùng và người vận hành. Ghi nhận ai phụ thuộc vào output, lỗi tạo tác động thực tế ở đâu và ai nghiệm thu kết quả.
• Behavior và policy — kiểm tra instruction, policy, skill, ticket, change request đã được phê duyệt và các chỉnh sửa lặp lại của con người. Chủ sở hữu phải xác nhận mọi quy tắc.
• Dependency — đối chiếu repository, package lock, model identifier, cấu hình connector, định nghĩa workflow, scheduler, console cloud và AI, data store, điểm đến monitoring và runtime log.
• Knowledge và memory — lập inventory tài liệu, database, object store, index, memory nền tảng, decision log và trạng thái workflow đang chờ. Ghi nhận chủ sở hữu, độ nhạy cảm, quy tắc truy cập, độ mới và retention.
• Permissions — xác minh IAM role, service account, OAuth scope, quyền API, cấu hình connector, cấu hình phê duyệt và audit log.
• Evaluation và vận hành — xây EVALS.jsonl từ công việc đã hoàn tất, sự cố, output bị từ chối và failure case. Xây runbook cùng những người thực sự tạm dừng, tiếp tục và khôi phục workload.

AI có thể giúp chuyển bằng chứng thành bản nháp đầu tiên, nhưng chủ sở hữu phải xác nhận kết quả. Đánh dấu thông tin còn thiếu là UNKNOWN hoặc NEEDS REVIEW. Không phỏng đoán quyền truy cập hay trạng thái workflow, và không đưa mật khẩu, API key, token hoặc dữ liệu khách hàng vào gói. HANDOFF.md có thể chỉ đồng nghiệp đến các tài liệu được quản trị; SKILL.md có thể đóng gói một năng lực có thể tái sử dụng. Hai loại tài liệu này có mục đích khác nhau.

Tiêu chí sẵn sàng

• Mỗi artifact có chủ sở hữu và ngày review.
• Dependency quan trọng có bằng chứng hỗ trợ.
• Không có secret và các điều chưa rõ được nêu rõ.
• Bộ evaluation có thể chạy lại.
• Quyền hạn thực tế đã được kiểm tra.
• Công việc đang chờ có một nguồn dữ liệu chuẩn.
• Một người vận hành khác đã kiểm thử runbook.

Gói tài liệu chỉ hữu ích khi mỗi thành phần có chủ sở hữu và ngày rà soát, dependency quan trọng có bằng chứng, không chứa secret, thông tin chưa rõ được ghi rõ, bộ đánh giá có thể chạy lại, quyền thực tế đã được kiểm tra, công việc đang chờ có nguồn dữ liệu chuẩn và một người vận hành khác đã thử runbook. Nếu đồng nghiệp không thể tiếp quản khi thiếu người tạo đứng bên cạnh, workload chưa sẵn sàng để chuyển - và có thể cũng chưa sẵn sàng để vận hành ổn định.

Từ khung migration đến migration contract có thể đọc bằng máy

Các nguyên tắc kiến trúc trong framework này chỉ hữu ích khi chúng được thể hiện rõ ràng, có thể review và kiểm thử trong một đợt migration thực tế.

Để hiện thực hóa điều đó, TitanBases đã khởi xướng AI Workload Migration Manifest (AWMM) — bản dự thảo đặc tả mở, trung lập nhà cung cấp nhằm mô tả và kiểm chứng AI workload migration giữa các runtime.

AWMM không thay thế giao thức interoperability, định dạng đóng gói agent hoặc cơ chế migration riêng của từng runtime. Thay vào đó, nó xác định migration contract bao quanh chúng: những gì phải chuyển, những gì cần transform hoặc bind lại, những gì có thể mất, rủi ro nào phải được kiểm soát, baseline hành vi và vận hành nào được áp dụng, acceptance gate nào phải pass, bằng chứng nào hỗ trợ kết quả và rollback được xử lý ra sao.

Sự phân biệt này là có chủ đích:

• Interoperable không có nghĩa là portable.
• Portable không có nghĩa là đã migrate.
• Import thành công không có nghĩa là tương đương về hành vi.

Một AWMM manifest có thể mô tả instruction, skill, công cụ, model, memory, dữ liệu retrieval, trạng thái workflow, danh tính, quyền hạn, policy, tham chiếu secret, observability, asset evaluation, dependency, transformation, rủi ro, baseline, acceptance gate, bằng chứng, provenance và yêu cầu rollback.

AWMM được thiết kế để cùng tồn tại với MCP, A2A, Agent Skills, định dạng durable state và hệ thống migration đặc thù runtime thay vì định nghĩa lại chúng. Các công nghệ đó có thể giải quyết từng vấn đề interoperability hoặc portability; AWMM mô tả cách các thành phần đó tham gia vào một đợt workload migration hoàn chỉnh.

Bản dự thảo đặc tả AWMM v0.1.0

Đặc tả được công bố có chủ đích ở trạng thái dự thảo. TitanBases không khẳng định AWMM là tiêu chuẩn ngành hoặc một manifest tuân thủ sẽ đảm bảo migration thành công. Mục đích của dự án là làm rõ đủ để có thể review và cải thiện công khai các giả định, khoảng trống, tiêu chí nghiệm thu và bằng chứng của migration.

Câu hỏi thường gặp về AI migration

AI migration là gì?

AI migration là quy trình có kiểm soát để chuyển hoặc tái tạo một workload AI trên model, nhà cung cấp, nền tảng hoặc agent runtime khác. Phạm vi có thể gồm model, instruction, tri thức, memory, công cụ, quyền hạn, trạng thái workflow, bộ đánh giá và kiểm soát vận hành.

AI migration có phải chỉ là đổi model hoặc API endpoint không?

Không. Đổi endpoint là phạm vi hẹp của model migration, được bài viết gọi là repoint theo bộ thuật ngữ đề xuất. Workload lớn hơn có thể còn phụ thuộc vào tri thức, công cụ, memory, danh tính, policy, trạng thái workflow và đánh giá trong môi trường production.

Có thể chuyển toàn bộ lịch sử hội thoại và memory sang AI khác không?

Có thể xuất một phần thông tin rồi định hình lại thành ngữ cảnh, tri thức được quản trị hoặc memory có cấu trúc. Memory gốc của nền tảng, hành vi runtime ẩn, trạng thái phiên đang chạy và cách model diễn giải thường không thể chuyển nguyên trạng. Hãy phân loại từng mục, xác minh nguồn và quyết định nên chuyển, kiểm chứng lại, để hết hạn hay loại bỏ.

SKILL.md hoặc HANDOFF.md có đủ để migrate agent không?

Không. Hai loại file này có thể giữ lại quy trình, instruction và đường dẫn đến tài nguyên hữu ích. Chúng không tự động chuyển quyền hạn, credential, trạng thái workflow, job theo lịch, memory gốc, lịch sử audit, dependency hay baseline đánh giá.

MCP và A2A có giải quyết được AI migration không?

Chúng hỗ trợ interoperability ở những ranh giới cụ thể: MCP kết nối ứng dụng AI với công cụ và tài nguyên, còn A2A hỗ trợ giao tiếp giữa các agent. Tự thân hai giao thức này không thực hiện discovery workload, chuyển trạng thái, kiểm chứng hành vi, cutover hay rollback.

Làm sao biết một đợt AI migration đã thành công?

Không nên đánh giá thành công bằng việc hai model tạo ra câu chữ giống hệt nhau. Hệ thống đích cần đáp ứng kết quả nghiệp vụ đã thống nhất, đồng thời duy trì quyền hạn, kiểm soát an toàn, hành vi công cụ và khả năng audit trong ngưỡng chất lượng, latency và chi phí được chấp nhận. Bộ đánh giá và chủ sở hữu nghiệp vụ cần xác định các ngưỡng đó trước cutover.

Doanh nghiệp nên bắt đầu chuẩn bị từ khi nào?

Hãy bắt đầu khi workload đi vào production hoặc bắt đầu tích lũy tri thức và ngữ cảnh vận hành có giá trị. Lập inventory dependency, thiết lập baseline đánh giá và ghi lại phương án rời nền tảng trước khi thay đổi nhà cung cấp khiến việc chuẩn bị trở nên cấp bách.

Kết luận: kiến trúc AI cần có đường rời đi

Làn sóng AI đầu tiên trong doanh nghiệp được thúc đẩy bởi tốc độ: model nào mạnh hơn, use case nào có thể xây nhanh và team nào đưa AI vào công việc trước. Thách thức tiếp theo là kiểm soát. Khi AI trở thành một phần của quy trình thực tế, tổ chức cần giải thích được hệ thống phụ thuộc vào đâu, được phép làm gì, kết quả được kiểm tra ra sao và điều gì sẽ xảy ra khi model hoặc nền tảng mà hệ thống đang dùng thay đổi.

AI migration không có nghĩa một dự án AI đã thất bại. Chủ đề này trở nên quan trọng khi workload đủ giá trị để tổ chức không thể chấp nhận mất tri thức, hành vi hoặc kiểm soát vận hành trong một lần thay đổi. Team biết đưa các tài sản đó ra ngoài và quản trị chúng có thể giữ lại năng lực đã xây dựng, đồng thời chỉ thay những phần thực sự cần thay. Nếu mọi thứ nằm trong một nền tảng, lock-in không còn dừng ở API contract mà đi sâu vào cách tổ chức làm việc.

Câu hỏi trưởng thành không chỉ là “Model mới nhất là gì?” mà còn là “Nếu ngày mai phải đổi model hoặc nền tảng, chúng ta có thể làm điều đó mà không mất năng lực, ngữ cảnh và quyền kiểm soát đang dựa vào không?” Kiến trúc AI tốt cần tính đến cách hệ thống bắt đầu, thay đổi và rời nền tảng hiện tại một cách có kiểm soát. Kế hoạch rời đi cần được đặt ra từ đầu, không phải đến cuối vòng đời.

Doanh nghiệp đang đánh giá mức độ phụ thuộc vào model, AI platform hoặc agent runtime hiện tại? Hãy bắt đầu bằng cách lập inventory workload, dependency và evaluation baseline trước khi chọn hướng migration.

Đọc thêm và tài liệu tham khảo

Chiến lược cloud migration (AWS Prescriptive Guidance)

Kiến trúc MCP (Model Context Protocol)

Tổng quan A2A và các khái niệm giao thức

Bài đọc liên quan của TitanBases: AI orchestration layer

Bài đọc liên quan của TitanBases: kỹ năng AI Architect