Kiến thức về xu hướng công nghệ FPT Cloud

Tại sự kiện công nghệ FPT Transform 2026 diễn ra ngày 17/10 diễn ra ở Hà Nội, FPT giới thiệu loạt giải pháp AI dành cho các doanh nghiệp chuyển từ giai đoạn thử nghiệm AI sang vận hành thực tế. Ông Lê Hồng Việt, phân tích thêm các cấp độ làm chủ AI phù hợp với từng doanh nghiệp, vai trò của dữ liệu và tri thức nội bộ trong tạo lợi thế cạnh tranh, cũng như cách lựa chọn mô hình, hạ tầng và phát triển năng lực công nghệ để giảm phụ thuộc vào bên ngoài. Theo ông, doanh nghiệp cần xác định mức độ làm chủ AI như thế nào để phù hợp với năng lực và mục tiêu kinh doanh?  Làm chủ AI hiện nay là yêu cầu bắt buộc với doanh nghiệp. Do đó, câu hỏi đặt ra không phải có làm hay không, mà là làm như thế nào. Mỗi tổ chức sẽ có năng lực công nghệ, nguồn lực và nhu cầu khác nhau nên cần lựa chọn mức độ làm chủ phù hợp. Doanh nghiệp có thể chia thành ba mức độ. Thứ nhất, với những đơn vị chưa có nhiều năng lực công nghệ, họ có thể bắt đầu từ các ứng dụng AI phục vụ những công việc thông dụng như mua sắm, bán hàng, nhân sự, marketing và quản trị. Ví dụ, giải pháp FPT AI EOS cho phép doanh nghiệp xây dựng các nhân sự số (digital worker) để thực hiện công việc cùng con người. Ngay cả tổng giám đốc cũng có thể tự xây dựng nhân sự số cho tổ chức của mình. Thứ hai, với những doanh nghiệp đã có nền tảng công nghệ nhưng chưa có năng lực chuyên sâu về AI, họ có thể sử dụng các nền tảng cung cấp mô hình có sẵn như FPT Token Factory. Cách tiếp cận này giúp doanh nghiệp lựa chọn mô hình phù hợp để giải quyết công việc, tối ưu chi phí và giảm gánh nặng vận hành hệ thống kỹ thuật. Thứ ba, với những công ty chuyên về AI, đã có đội ngũ kỹ sư AI, họ có thể sử dụng FPT Kubernetes Engine với GPU để tự xây dựng, lưu trữ, điều chỉnh và sử dụng mô hình theo nhu cầu. Như vậy, doanh nghiệp có thể bắt đầu từ việc sử dụng AI, sau đó, phát triển năng lực kỹ thuật để giải quyết những bài toán đặc thù. Mức độ làm chủ không nhất thiết phải giống nhau ở tất cả doanh nghiệp. Điều quan trọng là lựa chọn được cách tiếp cận phù hợp và từng bước nâng cao năng lực của mình. Doanh nghiệp cần ưu tiên những yếu tố nào để duy trì quyền chủ động về công nghệ? – Theo tôi, điều quan trọng nhất trước tiên là doanh nghiệp phải chủ động về dữ liệu. Dữ liệu tồn tại dưới hai dạng chính: dữ liệu giao dịch, thường được thể hiện bằng số liệu, và tri thức của doanh nghiệp được lưu trong các tài liệu, bản trình bày hoặc những nguồn thông tin nội bộ khác. Doanh nghiệp cần tổng hợp, làm sạch và tổ chức những dữ liệu này để cả con người lẫn AI có thể hiểu, khai thác được; sau đó, cần tiếp tục tích lũy tri thức. Đây là nền tảng để ứng dụng AI vào hoạt động và tạo ra những kết quả phù hợp với đặc thù của tổ chức. Bước tiếp theo là ứng dụng các tác nhân AI (AI Agent) để xây dựng lực lượng nhân sự số. Về lâu dài, mọi doanh nghiệp đều nên phát triển năng lực AI ít nhất đến mức kỹ thuật, đủ để xử lý những bài toán riêng của mình. Với mô hình và hạ tầng, doanh nghiệp cần lựa chọn phương án phù hợp với năng lực, yêu cầu sử dụng và mức độ kiểm soát mong muốn. Việc tự xây dựng mô hình đòi hỏi nguồn lực và chuyên môn cao, nên doanh nghiệp có thể khai thác các mô hình có sẵn trước khi tiến tới tự phát triển nếu cần thiết. Ở góc độ rộng hơn, làm chủ công nghệ còn gắn với chủ quyền công nghệ. Theo tôi, điều đó có nghĩa là ngay cả khi một quốc gia khác ngừng cung cấp công nghệ, hoạt động và quá trình phát triển của chúng ta vẫn có thể tiếp tục. Để đạt được mục tiêu này, Việt Nam cần có năng lực tự phát triển công nghệ, đồng thời tiếp nhận và cải tiến những công nghệ do cộng đồng xây dựng. Khi nhiều doanh nghiệp cùng sử dụng các mô hình AI có sẵn, yếu tố nào tạo nên lợi thế cạnh tranh riêng? – Để tự xây dựng và sử dụng mô hình AI riêng, doanh nghiệp cần năng lực rất cao. Khoảng 90-95% doanh nghiệp sẽ sử dụng các mô hình có sẵn từ những nền tảng cung cấp dịch vụ trong nước hoặc quốc tế. Điều này hoàn toàn bình thường, tương tự việc doanh nghiệp lựa chọn nhà cung cấp điện hay internet đáp ứng các tiêu chí của mình. Lợi thế cạnh tranh lớn nhất đến từ bí quyết và tri thức riêng của doanh nghiệp được tích lũy thành các thư viện tri thức. Khi xây dựng một AI Agent, những hướng dẫn đưa vào hệ thống cần được thiết kế bởi chính các chuyên gia của doanh nghiệp, dựa trên triết lý kinh doanh và cách thức hoạt động của tổ chức. Những hướng dẫn này định hình cách AI thực hiện công việc trong suốt quá trình vận hành. Vì vậy, dù hai doanh nghiệp có thể cùng sử dụng một mô hình nền tảng, cách AI xử lý công việc vẫn có thể khác nhau dựa trên tri thức, kinh nghiệm và hướng dẫn riêng của từng bên. Để tự làm chủ AI, doanh nghiệp cần cả một hệ sinh thái công nghệ. Họ có thể tận dụng các nền tảng trong nước và quốc tế để đưa AI vào nhiều công đoạn hoạt động trước, sau đó mới tiến tới tự phát triển AI. Theo tôi, doanh nghiệp cần làm chủ được việc ứng dụng AI vào hoạt động của mình, rồi từng bước nâng cao năng lực xây dựng công nghệ riêng. Ba sản phẩm FPT AI EOS, FPT Token Factory và FPT Kubernetes Engine với GPU vừa được FPT giới thiệu tại FPT Transform 2026 giải quyết những nhu cầu nào trong quá trình phát triển AI? – Ba sản phẩm được phát triển để đáp ứng những mức độ năng lực công nghệ khác nhau, đồng thời, kết nối các lớp trong quá trình đưa AI vào vận hành. Ở lớp ứng dụng, FPT AI EOS hỗ trợ doanh nghiệp xây dựng và vận hành các nhân sự số làm việc cùng con người. Thay vì chỉ phản hồi từng yêu cầu riêng lẻ, nhân sự AI có thể tham gia xuyên suốt quy trình, theo dõi công việc và phối hợp với các hệ thống doanh nghiệp đang sử dụng. Những quyết định quan trọng vẫn có thể được chuyển cho con người phê duyệt. Với lớp khai thác mô hình, FPT Token Factory cung cấp cổng truy cập thống nhất tới nhiều mô hình AI, gồm mô hình quốc tế, mô hình mở và các năng lực AI do FPT vận hành tại Việt Nam và Nhật Bản. Tùy yêu cầu về quy mô, hiệu năng và dữ liệu, doanh nghiệp có thể lựa chọn phương thức sử dụng phù hợp. Điều này giúp giảm sự phân mảnh khi phải làm việc với nhiều mô hình và nhà cung cấp khác nhau. Cuối cùng, ở lớp hạ tầng, FPT Kubernetes Engine với GPU cung cấp môi trường phục vụ các công việc AI từ huấn luyện, tinh chỉnh đến triển khai mô hình. Tài nguyên có thể mở rộng theo nhu cầu, đi kèm các công cụ quản trị, giám sát và bảo mật. Nhờ đó, đội ngũ phát triển có thể tập trung hơn vào sản phẩm thay vì phải tự xây dựng và vận hành toàn bộ hạ tầng GPU. Khi kết nối ba lớp này, doanh nghiệp có thể lựa chọn cách tiếp cận phù hợp, từ sử dụng ứng dụng AI, khai thác mô hình có sẵn đến tự phát triển và triển khai mô hình trên hạ tầng đáp ứng yêu cầu. Đây là cách chúng tôi xây dựng hệ sinh thái AI – Cloud – Data, giúp doanh nghiệp linh hoạt lựa chọn từng lớp theo nhu cầu và năng lực của mình. Theo ông, khó khăn lớn nhất của doanh nghiệp khi đưa AI từ thử nghiệm vào vận hành thực tế? – Khó khăn lớn nhất khi đưa AI vào vận hành là ý chí của lãnh đạo. AI là lĩnh vực còn mới. Nếu doanh nghiệp yêu cầu phải chứng minh hiệu quả đầu tư rồi mới cho phép thử nghiệm, quá trình ứng dụng sẽ gặp khó khăn vì chưa có đủ lịch sử để đánh giá. Doanh nghiệp cần thử nghiệm trước, có kết quả rồi mới đánh giá, cũng như chấp nhận một mức độ rủi ro nhất định để bắt đầu. Bên cạnh đó, doanh nghiệp cần thay đổi quy trình. Nếu chỉ đưa AI vào quy trình hiện tại và yêu cầu công nghệ làm việc giống hệt con người, khả năng thành công sẽ không cao. Khi AI làm thay đổi cách nhìn về năng lực và phương thức thực hiện công việc, quy trình cũng cần điều chỉnh để thích ứng. Chúng ta phải khai thác những điểm mạnh của trí tuệ nhân tạo, thay vì chỉ yêu cầu công nghệ bắt chước cách con người đang làm. Việc giám sát AI cũng cần được tính đến ngay từ đầu. Với những công cụ phù hợp, người quản lý có thể theo dõi chi tiết hệ thống đã và đang thực hiện công việc gì. Ví dụ, FPT AI EOS cho phép doanh nghiệp giám sát hoạt động của nhân sự số, đồng thời xác định những công việc cần chuyển cho con người kiểm soát. Điều này tạo điều kiện để doanh nghiệp ứng dụng AI vào nhiều công đoạn mà vẫn duy trì quyền giám sát đối với các quyết định quan trọng. Cuối cùng, hiệu quả của AI vẫn cần được đánh giá theo những tiêu chí kinh doanh cơ bản: doanh số có tăng trưởng không, lợi nhuận có tăng không và năng suất lao động có cải thiện không. Việc đánh giá không khác với các khoản đầu tư thông thường, nhưng cách triển khai và quyết tâm của doanh nghiệp sẽ quyết định kết quả. Hệ sinh thái AI – Cloud – Data cần phát triển như thế nào để doanh nghiệp Việt Nam tăng năng lực tự chủ và sức cạnh tranh? – Theo tôi, năng lực làm chủ AI có hai yếu tố. Thứ nhất là năng lực sử dụng AI. Đây là khả năng mọi doanh nghiệp cần trang bị ngay từ bây giờ. Trong ngắn hạn, nếu không sử dụng AI, doanh nghiệp sẽ có nguy cơ tụt lại phía sau. Thứ hai là năng lực của cộng đồng công nghệ Việt Nam trong việc phát triển các mô hình, hạ tầng và ứng dụng riêng để giảm sự phụ thuộc vào nước ngoài. Đây là bài toán dài hạn, đòi hỏi quá trình nghiên cứu, phát triển, tiếp nhận và cải tiến công nghệ. Với FPT, chúng tôi xây dựng hệ sinh thái theo ba lớp: ứng dụng ở trên cùng, nền tảng ở giữa và phần cứng hạ tầng ở dưới. Các lớp được xây dựng trên hệ thống hạ tầng mà FPT đã đầu tư. Cách tiếp cận này giúp nhiều nhóm khách hàng lựa chọn giải pháp theo nhu cầu, từ doanh nghiệp cần ứng dụng AI nhanh chóng đến những đơn vị có đội ngũ kỹ sư muốn phát triển và vận hành mô hình riêng. Chúng tôi cũng mong muốn chia sẻ kiến thức, kinh nghiệm xây dựng và vận hành nền tảng để cộng đồng công nghệ có thể khai thác, chủ động phát triển, tùy biến và triển khai các mô hình, ứng dụng AI, phục vụ những bài toán thực tiễn. Mục tiêu là tạo điều kiện để nhiều đối tượng tham gia sáng tạo, từ kỹ sư công nghệ đến nhân sự kinh doanh và người dùng phổ thông. Về lâu dài, năng lực cạnh tranh của doanh nghiệp Việt Nam sẽ gắn với khả năng ứng dụng AI hiệu quả và năng lực phát triển công nghệ của chính mình. Chúng ta cần vừa tận dụng những thành tựu sẵn có, vừa từng bước xây dựng mô hình, hạ tầng và ứng dụng riêng để duy trì khả năng chủ động trong quá trình phát triển.

Từ năm 2020, FPT Cloud được xây dựng bởi hơn 400 kỹ sư Việt Nam, từ tầng hạ tầng lõi đến AI và bảo mật. Bảy bức ảnh dưới đây kể lại hành trình ấy, cùng những con số về hơn 3.000 doanh nghiệp đồng hành. Năm 2020, Tập đoàn FPT thành lập FPT Smart Cloud, giao ông Lê Hồng Việt, khi ấy là Giám đốc Công nghệ của Tập đoàn, làm Tổng Giám đốc. Cùng năm đó, FPT Cloud ra mắt thị trường. Từ hạ tầng mã nguồn mở OpenStack, hơn 400 kỹ sư Việt Nam trực tiếp vận hành và tùy biến tầng lõi, rồi từng bước xây thêm các tầng cloud-native, dữ liệu, AI và bảo mật, tạo nên bộ gần 100 dịch vụ. Trên nền đó, FPT AI Factory cùng NVIDIA phát triển hơn 3.000 GPU, vận hành tại Việt Nam và Nhật Bản. Song song, tháng 8/2025, Bộ Công an xác nhận FPT Cloud đáp ứng An toàn hệ thống thông tin Cấp độ 4, còn FPT AppSec đạt giải Cybersecurity Excellence Awards 2026. Nhờ vậy, hơn 3.000 doanh nghiệp đã đồng hành cùng FPT Cloud, với chi phí đầu tư, vận hành giảm 30% so với mô hình on-premise. Hạ tầng đạt Tier III, SLA 99,99%, vận hành tại ba vùng. Từ đó, FPT Cloud hướng tới mở rộng khách hàng và doanh thu quốc tế.

Deploy tăng 30%, rollback tăng 50%: thay đổi tư duy đọc DORA metrics khi việc tạo code quá nhanh và dễ dàng với AI  AI đang được sử dụng để viết code ngày càng nhiều, tốc độ cũng ngày càng nhanh. Đối với vai trò quản lý kỹ thuật hiện nay hầu hết đã từng hoặc sẽ sớm gặp tình huống này: trong hai kỳ có cùng độ dài, một dịch vụ tăng từ 100 lên 130 lần triển khai, nhưng số deployment phải rollback cũng tăng từ 10 lên 15. Người phụ trách phát triển (VP Engineering) nhận định kết quả này là một thành công: tốc độ tăng rõ rệt, còn rollback là "chi phí học hỏi" tạm thời nên cần nhân rộng mô hình ngay. Người phụ trách độ tin cậy (SRE) thì ngược lại, xem đây là tín hiệu báo động hệ thống đang xuống cấp và phải rà soát gấp trước khi có sự cố lớn.  Những tranh luận ngược chiều cho cùng kết quả tương tự này đang diễn ra ở các đội ngũ kỹ thuật khắp thế giới, từ báo cáo DORA của Google đến các bộ benchmark hàng triệu pull request.  Một người có kinh nghiệm vận hành sẽ hiểu rằng số lần triển khai tăng cùng số lần rollback chưa đủ để kết luận AI đang giúp hay làm khó đội ngũ lập trình, mà cần phân biệt lượng công việc, tỷ lệ triển khai thất bại và mức ảnh hưởng tới người dùng trước khi quyết định mở rộng. Trong ví dụ giả định bên trên, số deployment phải rollback tăng 50%, còn tỷ lệ tăng từ 10% lên 11,54%: chênh 1,54 điểm phần trăm, tương đương tăng khoảng 15,4% tương đối. Phép tính là (1,5 / 1,3 − 1) × 100%. Hai mức tăng mô tả hai khía cạnh khác nhau: tổng số lần cần xử lý và tỷ lệ deployment cần hoàn tác. Kết quả phép tính không thể hiện được bản chất của ảnh hưởng bởi vì 15 lần rollback tự động, ít tác động tới người dùng có thể tạo gánh nặng khác hẳn 10 lần khôi phục kéo dài.   Để đánh giá hiệu quả của AI, chúng ta còn phải biết những deployment tăng thêm mang lại thay đổi gì và đội ngũ tốn bao nhiêu công sức để đưa chúng vào vận hành.  Báo cáo DORA 2025 phơi bày sự ảo tưởng về năng suất khi dùng AI  Báo cáo DORA 2024 1 đi ngược kỳ vọng của nhóm nghiên cứu: cứ mỗi 25% tăng mức áp dụng AI đi kèm mức giảm ước tính 1,5% ở throughput (tốc độ/lưu lượng bàn giao) và 7,2% ở delivery stability (độ ổn định phân phối). Trong khi AI giúp tăng năng suất cá nhân (viết code, làm tài liệu), nó lại gây tắc nghẽn ở quy trình kiểm thử/review và đưa code lên hệ thống thật, dẫn tới tốc độ bàn giao chung bị chậm đi nhẹ và độ lỗi/bất ổn định tăng lên.  Báo cáo DORA 2025 (State of AI-assisted Software Development)2 ghi nhận bước ngoặt lớn: việc áp dụng AI đã thực sự giúp tăng tốc độ bàn giao (throughput chuyển từ âm sang dương). Tuy nhiên, mức áp dụng AI vẫn tỉ lệ thuận với tỷ lệ thất bại khi thay đổi (CFR), nghĩa là AI giúp làm nhanh hơn nhưng hệ thống vẫn kém ổn định như trước.   Một năm nâng cấp công cụ AI giúp tăng tốc bàn giao nhưng lại không giảm bớt lỗi hệ thống, chứng minh rằng nguyên nhân không nằm ở chất lượng công cụ kém hoặc lỗi do lập trình viên “chưa quen tay", mà do quy trình vận hành hiện tại có lỗ hổng về mặt kiến trúc.  Bất ổn luôn tồn tại nếu quy trình vận hành kiểm thử của con người không theo kịp tốc độ viết code của AI  Trước khi có AI, viết code là khâu tốn thời gian nhất (bottleneck). Lập trình viên mất nhiều giờ suy nghĩ, viết từng dòng nên họ hiểu rất rõ logic code của mình. Khi họ tạo PR (Pull Request), dung lượng PR nhỏ và dễ review. Khi đưa AI vào làm việc, AI giúp sinh hàng trăm dòng code chỉ trong vài giây. Tuy nhiên, quy trình review code (kiểm thử tự động, đọc hiểu logic, đánh giá bảo mật, chạy thử) vẫn tốn dung lượng bộ nhớ/thời gian suy nghĩ của con người. Việc bơm một lượng code cực lớn vào một quy trình kiểm duyệt có năng lực giới hạn sẽ tự động tạo ra nút nghẽn (bottleneck) mới và bỏ sót lỗi ra môi trường thật. Dữ liệu benchmark độc lập của LinearB (báo cáo benchmark 2026), phân tích 8,1 triệu pull request từ khoảng 4.800 team kỹ thuật tại 42 quốc gia, chỉ đích danh nút nghẽn. PR có AI hỗ trợ chỉ đạt tỷ lệ merge 32,7% trong 30 ngày, so với khoảng 84,5% của PR người viết. Thời gian chờ được review dài gần 5 lần (khoảng 960 phút so với ~200 phút), và PR cũng lớn hơn hẳn: từ 400 dòng trở lên so với 157 dòng ở phân vị 75. Chi phí tạo code đã sụp xuống, còn chi phí kiểm chứng thì không.  Bản chất Mô hình Ngôn ngữ Lớn (LLM): AI sinh code bằng cách dự đoán từ tiếp theo dựa trên xác suất, không phải bằng tư duy logic hệ thống. Code do AI tạo ra có thể trông rất "mượt" và chạy đúng ở các case cơ bản (happy path), nhưng dễ bỏ qua các trường hợp biên (edge cases), ngoại lệ bảo mật hay tính tương thích với hạ tầng hiện có. Nếu đưa AI vào quy trình theo kiểu "ủy thác viết code" mà không nâng cấp quy trình kiểm thử tương ứng, hệ thống sẽ liên tục dung nạp các đoạn code tiềm ẩn lỗi ngầm.  Việc đọc hiểu và phát hiện lỗi trong 500 dòng code do AI viết tốn nhiều năng lượng não bộ hơn rất nhiều so với việc review code do đồng nghiệp tự tay viết. Chính DORA chỉ ra cơ chế: thời gian tiết kiệm ở khâu viết code đã bị dồn sang khâu đánh giá và kiểm chứng, khi có tới 30% kỹ sư thừa nhận họ ít hoặc không tin tưởng code do AI sinh ra.3 Khi xảy ra sự cố trên môi trường vận hành thực tế (production), kỹ sư trực ca (SRE/DevOps) phải sửa những dòng code mà chính họ không hề viết từ đầu, điều này làm kéo dài thời gian xử lý sự cố.   Tóm lại, Bất ổn định là thuộc tính cấu trúc vì chúng ta đang dùng công cụ của kỷ nguyên AI (sinh code cực nhanh) nhưng lại chạy trên quy trình vận hành của kỷ nguyên cũ (review và test thủ công/bằng con người). Nếu chỉ đẩy mạnh dùng AI để tạo code mà không thay đổi cấu trúc quy trình (như tự động hóa test, chia nhỏ PR, tăng cường AI review), thì tốc độ tăng đến đâu, rủi ro và bất ổn sẽ tăng tương ứng đến đó.   Thay đổi tư duy đọc DORA Metrics từ “đo KPI" sang “đo nút nghẽn"  Trong bộ 4 chỉ số DORA (2 chỉ số Tốc độ + 2 chỉ số Ổn định), công cụ AI chỉ tác động trực tiếp và làm tăng tức thì đúng 1 chỉ số duy nhất là Tần suất triển khai (Deployment Frequency).   Chỉ số AI tác động qua kênh nào? Chiều tác động Độ trễ trước khi chỉ số nói thật Tần suất triển khai (Deploy frequency) Trực tiếp: chi phí tạo code giảm thì số thay đổi và số lần deploy tăng gần như tự động Tăng ngay khi bật AI assistant, chưa cần biết code tốt hay xấu. Không có độ trễ - đây chính là gốc rễ của ảo tưởng về năng suất của AI. Thời gian hoàn thành (Lead time for changes) Gián tiếp: thời gian viết code rút ngắn lại nhưng thời gian review và kiểm chứng kéo dài, bị nghẽn lại Hai lực ngược chiều triệt tiêu nhau; con số tổng dễ đứng yên, che đậy sự dịch chuyển nút nghẽn. Số trung bình che đậy độ lệch, phải tách pha viết và pha review mới thấy. Tỷ lệ lỗi / Tỷ lệ làm lại (Change failure rate / Rework rate) Gián tiếp: Phản ánh qua chất lượng thực tế của code khi chạy trên Production. Tăng tỉ lệ thuận khi khối lượng code AI chưa kiểm soát bùng nổ. Trễ từ một đến vài chu kỳ release. Thời gian khôi phục dịch vụ (MTTR) Gián tiếp: Phản ánh năng lực đọc hiểu và làm chủ hệ thống của kỹ sư lúc xảy ra sự cố. Nguy cơ kéo dài: Kỹ sư trực ca phải sửa những dòng code do AI viết mà họ chưa từng đọc kỹ. Trễ nhất, chỉ bộc lộ khi có sự cố lớn xảy ra trên Production.  Bảng phân tích trên giải thích lý do vì sao dashboard ở các buổi review quý thường tạo ra hai góc nhìn trái ngược.   AI không làm cho DORA metrics vô dụng, nhưng nó bắt chúng ta phải thay đổi hoàn toàn cách đọc. Đọc DORA thời AI không phải để đếm xem team bận rộn ra sao, mà là để nhận diện nút nghẽn đã dịch chuyển về đâu và ngăn chặn rủi ro sập hệ thống trước khi quá trễ. Để nhận diện đúng sức khỏe hệ thống, quản lý kỹ thuật cần thay đổi tư duy khi phân tích báo cáo:  Tuyệt đối không đọc đơn độc chỉ số Tốc độ (Deployment Frequency / Lead Time): Bắt buộc phải đọc sóng đôi với Chỉ số Ổn định (Change Failure Rate, hoặc Rework Rate — chỉ số bổ trợ ngoài bộ 4 chỉ số DORA) trên cùng một màn hình quan sát. Việc tách rời hai nhóm chỉ số này sẽ tạo ra "ảo tưởng về tốc độ", che đậy rủi ro tích tụ ở khâu kiểm thử.  Tách bạch nguồn dữ liệu (AI vs. Non-AI): Bắt buộc phải đo lường riêng biệt các PR có AI hỗ trợ và PR do con người tự viết hoàn toàn. Nếu gộp chung, lãnh đạo sẽ liên tục rơi vào bẫy "nhiễu" số liệu - nơi các chỉ số trung bình làm mờ đi bản chất vấn đề như ví dụ tranh luận ở đầu bài.  Áp dụng vào hệ thống của bạn:   Hãy mở dashboard quản lý hiện tại và đếm xem có bao nhiêu chỉ số tốc độ đang đứng đơn độc mà không có chỉ số ổn định đi kèm. Con số đó sẽ cho bạn biết hệ thống đang thực sự đo sức khỏe vận hành, hay chỉ đang "đếm dòng code" cùng AI.  Nhận diện được nút nghẽn mới chỉ là bước đầu tiên. Làm sao để điều chỉnh quy trình kiểm thử và review code để giải phóng nút nghẽn này mà không làm chậm tốc độ của đội ngũ? Chúng ta sẽ cùng giải bài toán này ở bài viết tiếp theo: "Tái cấu trúc quy trình vận hành khi AI tham gia viết code: 3 nguyên tắc bắt buộc".  Nguyễn Phương Lan  Trưởng Phòng Điều Hành Sản Xuất FPT Cloud  Câu hỏi thường gặp  DORA metrics là gì?  DORA (DevOps Research and Assessment) là chương trình nghiên cứu của Google về hiệu năng phân phối phần mềm, với bốn chỉ số kinh điển gồm:  Tần suất triển khai (deploy frequency)   Thời gian từ commit đến production (lead time for changes)  Tỷ lệ thay đổi gây lỗi trên production (change failure rate)  Thời gian khôi phục sau sự cố (MTTR; DORA gần đây đổi tên thành Failed deployment recovery time)  Rework rate khác change failure rate ở điểm nào?  Change failure rate đếm tỷ lệ thay đổi gây ra sự cố chính thức trên Production (Môi trường thực tế). Rework rate đếm tỷ lệ deploy sinh ra chỉ để sửa hệ quả của đợt deploy trước, nên nó bắt được cả những lần sửa chữa ngầm không đi kèm báo cáo sự cố. Với code AI, Rework rate nhạy hơn vì phần lớn chi phí ẩn nằm ở việc phải sửa đi sửa lại.  Làm sao biết bao nhiêu phần trăm code do AI viết?  Gắn nhãn tại nguồn (Tagging at source): thông qua IDE Plugin, PR Label (Nhãn trên Pull Request) hoặc Commit Trailer ngay từ lúc tạo thay đổi. Các phương pháp Retrospective Estimation (Ước lượng hồi tố) bằng cảm nhận hay khảo sát đều không đủ tin cậy để đưa vào chỉ số vận hành.  

AI đang viết một tỷ lệ ngày càng lớn lượng code mới của thế giới với tốc độ nhanh hơn mọi quy trình security review truyền thống có thể theo kịp. Phần lớn doanh nghiệp không thiếu công cụ bảo mật mà họ thiếu context: khả năng ghép hàng trăm cảnh báo rời rạc thành đường tấn công, cho thấy kẻ tấn công sẽ đi từ đâu đến đâu. Bài viết phân tích vì sao tốc độ của AI buộc bảo mật phải thay đổi ở tầng kiến trúc thay vì bổ sung công cụ, và cách chúng tôi giải bài toán đó với FPT Cloud Security Platform.  AI làm code nhanh hơn, lỗ hổng bảo mật cũng nhiều hơn  75% dòng code mới tại Google hiện do AI tạo ra, theo công bố của CEO Alphabet Sundar Pichai. Kevin Scott, CTO Microsoft dự báo con số này tiến tới 95% trong 5 năm tới. GenAI đang dẫn đầu tăng trưởng trong các dịch vụ public cloud: mức sử dụng tăng 8 điểm phần trăm (percentage point) lên 58%, với 45% tổ chức đã triển khai ở quy mô lớn (Flexera, 2026 State of the Cloud Report). Gartner nhận định tới năm 2028, điện toán đám mây chuyển từ vai trò công nghệ đột phá thành cấu phần bắt buộc của năng lực cạnh tranh. Tại Việt Nam, thị trường cloud được dự báo đạt 6,98 tỷ USD vào năm 2030, CAGR 10,94% (TechSci Research). Cloud đã không còn chỉ là nơi đặt máy chủ mà trở thành nền tảng nơi phần mềm và AI được tạo ra, triển khai và vận hành.  Khoảng cách giữa tốc độ phát triển và tốc độ bảo mật ngày càng lớn  Cái giá của những dòng “code nhanh” từ AI không nằm ở màn hình người viết. 61% kỹ sư đánh giá code do AI tạo "trông đúng nhưng chưa chắc đáng tin" (Sonar, State of Code Developer Survey 2026).   Veracode, trong GenAI Code Security Report 2025, đo tỷ lệ code do AI sinh ra không vượt qua kiểm tra bảo mật theo từng ngôn ngữ:  Ngôn ngữ  Tỷ lệ code AI-generated không vượt qua kiểm tra bảo mật  Java  72%  C#  45%  JavaScript  43%  Python  38%  Nguồn: Veracode, 2025 GenAI Code Security Report  Đây không phải bài toán riêng của doanh nghiệp dùng AI viết phần mềm. Code do AI tạo đang chảy vào mọi hệ thống qua thư viện mã nguồn mở, đối tác gia công và nhà cung cấp phần mềm. Ở chiều ngược lại, tin tặc dùng AI để dò lỗ hổng và tự động hóa khai thác. 94% lãnh đạo trong khảo sát của Diễn đàn Kinh tế Thế giới coi AI là động lực thay đổi lớn nhất của an ninh mạng (WEF Global Cybersecurity Outlook 2026).    6 “điểm đau” bảo mật doanh nghiệp thường mắc phải  security tham gia quá muộn, lỗi chỉ được phát hiện sau khi release;   mỗi giai đoạn phát triển dùng một công cụ riêng, không chia sẻ dữ liệu;   nhiều dashboard nhưng không có bức tranh tổng thể;   đội vận hành ngập trong cảnh báo tới mức chai lì (alert fatigue);   báo động giả (false positive) bào mòn niềm tin vào chính công cụ;   và khi mọi cảnh báo đều "đỏ", không còn gì thực sự quan trọng.  Hầu hết tổ chức tập trung phòng thủ luồng North-South - traffic ra vào giữa Internet và hệ thống nội bộ, nơi dễ nhận diện và chặn bằng gateway hay WAF. Luồng East-West - giao tiếp giữa các server, ứng dụng và database - chiếm khoảng 70-80% tổng traffic nhưng hiếm khi được kiểm soát tương xứng: thiếu microsegmentation và giám sát nội vùng, kẻ tấn công chỉ cần vượt qua perimeter một lần là di chuyển ngang (lateral movement) gần như tự do để tiếp cận dữ liệu.  Điểm mấu chốt: một quyền truy cập cấp quá rộng, một cổng dịch vụ mở, một lỗ hổng ứng dụng đứng riêng lẻ đều vô hại trong báo cáo của từng công cụ; ghép đúng trình tự, chúng là một đường tấn công (attack path) hoàn chỉnh. Không công cụ đơn lẻ nào nhìn thấy phép ghép đó, vì mỗi công cụ chỉ giữ một mảnh dữ liệu. Giới bảo mật gọi đây là bất đối xứng kinh điển, theo định đề của John Lambert (Microsoft Threat Intelligence): "Defenders think in lists. Attackers think in graphs. As long as this is true, attackers win."  FPT Cloud Security Platform: kết nối các dấu vết rời rạc, chỉ rõ đường tấn công   Nguyên tắc thiết kế của chúng tôi xuất phát từ chẩn đoán trên: nếu vấn đề là context, lời giải phải bắt đầu từ tầng dữ liệu, không phải từ việc bổ sung tính năng. Nền tảng được tổ chức thành ba tầng, theo thứ tự dữ liệu được xử lý.  Security Data Lake gom log tường lửa, sự kiện container, kết quả quét lỗ hổng và API call trên cloud về một nơi duy nhất, lưu trữ tại Việt Nam. Với CISO, điều này nghĩa là một giao diện duy nhất, thay vì gộp báo cáo thủ công từ nhiều tính năng bảo mật rời rạc.  Security Graph nối các tín hiệu trong data lake thành đường tấn công cụ thể - cho thấy nếu bị khai thác, kẻ tấn công sẽ đi từ đâu đến đâu. Đây là tầng trả lời câu hỏi ưu tiên: từ 500 cảnh báo không rõ mức độ, hệ thống lọc còn 5 lỗ hổng nằm trên đường tấn công khả thi dẫn tới tài sản quan trọng.  AI Security Engine làm việc trên cùng context đó với ba nhiệm vụ: AI Triage đọc context của từng phát hiện trước khi quyết định có báo động hay không, thay vì đẩy mọi phát hiện cho con người; AI Correlation nối tín hiệu từ code, runtime và cấu hình cloud để phát hiện những kiểu tấn công mà luật cố định (rule-based) bỏ sót; AI Remediation không dừng ở việc chỉ ra lỗi, mà đề xuất đoạn code cần sửa kèm lý do.  AI giảm tải chứ không thay quy trình. Dù tầng AI lọc được phần lớn nhiễu, luôn có một tỷ lệ phát hiện phải do con người phân tích và quyết định - thường là những ca khó nhất, nơi rủi ro kỹ thuật đan với bối cảnh nghiệp vụ. Tổ chức vẫn cần quy trình phản hồi, người chịu trách nhiệm và kỷ luật vá lỗi; nền tảng chỉ bảo đảm thời gian của đội ngũ dồn vào đúng phần đáng dồn  Lộ trình từ Code -> Security Platform  AppSec chạy song song sáu lớp quét - SAST, secret scan, IaC scan, container image scan, DAST API scan - tích hợp thẳng vào CI/CD theo hướng shift-left. Khác biệt nằm ở pipeline suy luận sâu: source code được phân tích qua AST, data flow, taint analysis, rồi tới bước AI reasoning chạy trên FPT AI Factory để đưa ra kết luận theo context (context-aware verdict). Kết quả từ tất cả các lớp đổ về một correlation engine, xếp hạng rủi ro theo khả năng khai thác (exploitability), phạm vi ảnh hưởng (blast radius) và tác động kinh doanh - hiển thị trên một dashboard chung cho Dev, Sec và Ops. Cách gom mọi rủi ro về một đồ thị phân tích duy nhất cắt 80-90% cảnh báo rác.  Auto-triage là một cơ chế suppression, và mọi cơ chế suppression đều có xác suất nén nhầm một phát hiện thật. Đổi lấy việc cắt 80-90% cảnh báo rác là rủi ro false negative, và rủi ro đó phải được quản trị bằng thiết kế chứ không bằng niềm tin vào mô hình. Ba nguyên tắc chúng tôi áp dụng: chỉ tự động đóng khi mức tin cậy vượt ngưỡng đặt trước, dưới ngưỡng thì hạ mức ưu tiên chứ không tắt cảnh báo; một số lớp không bao giờ được tự động đóng, gồm secret bị lộ, lỗ hổng trên bề mặt hướng Internet và tài sản thuộc nhóm quan trọng nhất; và mọi quyết định suppress đều lưu lại tín hiệu cùng lý do dẫn tới nó để truy vết ngược khi cần. Đi kèm là một chỉ số vận hành ít được nhắc nhưng quan trọng nhất với tầng này: tỷ lệ phát hiện từng bị nén rồi sau đó được xác nhận là thật. Nếu con số ấy không được đo, không thể khẳng định cơ chế đang chạy đúng.  Với các tổ chức thuộc phạm vi điều chỉnh của quy định trong nước, nền tảng tự động phát hiện sai lệch cấu hình và xuất báo cáo làm bằng chứng tuân thủ khi kiểm tra, đánh giá định kỳ. Từ 01/7/2026, Luật An ninh mạng số 116/2025/QH15 hợp nhất và thay thế Luật An toàn thông tin mạng 2015 cùng Luật An ninh mạng 2018; cơ chế bảo vệ theo 5 cấp độ nay được chi tiết hóa tại Nghị định 331/2026/NĐ-CP (19/8/2026) — văn bản thay vai trò của Nghị định 85/2016/NĐ-CP và Thông tư 12/2022/TT-BTTTT, bổ sung yêu cầu đánh giá rủi ro, rà quét lỗ hổng và kiểm thử xâm nhập. Hệ thống đã phê duyệt cấp độ theo luật cũ phải cập nhật biện pháp bảo vệ trong 12 tháng kể từ ngày Luật có hiệu lực; ở phía ngân sách, Điều 38 yêu cầu dành tối thiểu 15% kinh phí dự án chuyển đổi số dùng ngân sách nhà nước cho an ninh mạng.  Hợp nhất context đồng nghĩa với tập trung dữ liệu bảo mật - và kho dữ liệu ấy tự nó là mục tiêu giá trị cao. Log bảo mật thường chứa cả secret bị lộ lẫn dữ liệu cá nhân, nên đi kèm nó phải là phân quyền theo least privilege, mã hóa khi lưu và khi truyền, quản lý khóa tách biệt, audit log truy cập, cùng chính sách retention và masking - thiết kế từ đầu, không bổ sung sau. Đây là nghĩa vụ pháp lý: Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15 và Nghị định 356/2025/NĐ-CP (hiệu lực 01/01/2026, thay Nghị định 13/2023) buộc lập hồ sơ DPIA và đánh giá tác động chuyển dữ liệu ra nước ngoài trong 60 ngày, bố trí nhân sự bảo vệ dữ liệu, thông báo vi phạm trong 72 giờ với dữ liệu vị trí và sinh trắc học. Mức phạt tới 3 tỷ đồng, hoặc 5% doanh thu năm liền trước với vi phạm chuyển dữ liệu xuyên biên giới, chi tiết tại Nghị định 330/2026/NĐ-CP (hiệu lực 05/10/2026). Data lake đặt tại Việt Nam đáp ứng yêu cầu vị trí lưu trữ theo Điều 19 Nghị định 333/2026/NĐ-CP (thay Nghị định 53/2022) và sàn retention nhật ký tối thiểu 12 tháng; nếu dữ liệu chạm ngưỡng "quan trọng"/"cốt lõi" theo Quyết định 20/2025/QĐ-TTg thì áp thêm nghĩa vụ đánh giá rủi ro hằng năm của Luật Dữ liệu 60/2024/QH15 và Nghị định 165/2025/NĐ-CP.  Nội dung bài viết là thông tin kỹ thuật, không phải tư vấn pháp lý.  Tác Giả: Bùi Song Toàn  Bùi Song Toàn là Phó Giám đốc Trung tâm Phát triển dịch vụ Nền tảng Cloud, FPT Smart Cloud, với hơn 10 năm kinh nghiệm trong hạ tầng CNTT và platform engineering. Ông phụ trách phát triển lớp dịch vụ nền tảng trên FPT Cloud: Kubernetes và container platform, CI/CD cùng các dịch vụ platform engineering, data platform, observability, hạ tầng phục vụ AI, và nhóm dịch vụ bảo mật nền tảng - trong đó có FPT Cloud Security Platform và FPT AppSec.   

Nhằm mang đến trải nghiệm quản trị cơ sở dữ liệu tối ưu và an toàn nhất, FPT Database Engine chính thức cập nhật bộ ba tính năng mới: Engine Version Upgrade, Point-in-Time Recovery (PITR) và hỗ trợ OpenSearch Version 3.5.0. Những nâng cấp này là "chìa khóa" giúp doanh nghiệp giải quyết bài toán vận hành phức tạp, bảo vệ dữ liệu toàn vẹn và dễ dàng tiếp cận các nền tảng cơ sở dữ liệu thế hệ mới. Engine Version Upgrade: Nâng cấp database trực tiếp trên cluster hiện có Trước đây, việc cập nhật phiên bản cơ sở dữ liệu thường là "nỗi ám ảnh" của các kỹ sư hệ thống khi đòi hỏi phải triển khai một cluster hoàn toàn mới, sau đó thực hiện chuyển đổi dữ liệu với rất nhiều thao tác rủi ro và tốn kém thời gian.  Với Engine Version Upgrade, FPT Database Engine cho phép khách hàng nâng cấp phiên bản database engine trực tiếp trên cluster hiện có thông qua FPT DBaaS Portal mà không cần tạo database cluster mới, giúp đơn giản hóa việc quản lý vòng đời database và giảm thiểu công việc vận hành. Thông qua FPT DBaaS Portal, khách hàng có thể thực hiện nâng cấp trực tiếp, kiểm tra điều kiện trước khi nâng cấp và theo dõi tiến trình thực hiện.  Tính năng mang lại các lợi ích:  Đa dạng nền tảng: Hỗ trợ nâng cấp (Patch Upgrade và Minor Upgrade) cho các engine phổ biến gồm: MySQL, Redis, MongoDB Standard và Kafka. Thao tác trực quan, dễ dàng: Khách hàng có thể chủ động kiểm tra các điều kiện cần thiết trước khi nâng cấp và theo dõi sát sao toàn bộ tiến trình thực hiện ngay trên giao diện FPT DBaaS Portal. An toàn và tương thích: Hệ thống chỉ cho phép cập nhật lên các phiên bản đã được đội ngũ chuyên gia FPT kiểm thử và chứng nhận độ ổn định.   Lưu ý: Engine Version Upgrade chỉ hỗ trợ theo các đường nâng cấp (Upgrade Path) do FPT Database Engine cung cấp. Trong quá trình nâng cấp, database cluster sẽ được khởi động lại (restart) và có thể xảy ra gián đoạn dịch vụ trong thời gian ngắn. FPT khuyến nghị thực hiện nâng cấp trong Maintenance Window hoặc ngoài giờ cao điểm, đồng thời thực hiện backup trước khi nâng cấp nhằm đảm bảo an toàn dữ liệu. Point-in-Time Recovery (PITR): Khôi phục dữ liệu về thời điểm mong muốn Trong quá trình vận hành database, các sự cố như thao tác nhầm, lỗi ứng dụng hoặc thay đổi dữ liệu ngoài mong muốn có thể ảnh hưởng đến trạng thái dữ liệu hiện tại. Vì vậy, khả năng khôi phục chính xác dữ liệu tại một thời điểm cụ thể là yêu cầu quan trọng để đảm bảo tính liên tục của hệ thống.  FPT Database Engine bổ sung tính năng Point-in-Time Recovery (PITR) cho phép doanh nghiệp khôi phục cơ sở dữ liệu về bất kỳ thời điểm hợp lệ nào trong khoảng thời gian lưu trữ, thay vì chỉ phụ thuộc vào các bản backup định kỳ. Tính năng được áp dụng cho các dịch vụ: PostgreSQL, MySQL và MariaDB. Các khả năng chính: Lựa chọn thời điểm khôi phục: Khôi phục chính xác trạng thái dữ liệu tại một thời điểm tùy chọn trong phạm vi lưu trữ cấu hình. Khởi tạo instance độc lập: Dữ liệu được khôi phục sang một database instance mới, hoàn toàn không ghi đè lên database gốc hiện tại. Quản lý chủ động: Cho phép bật/tắt PITR trên từng cluster, cấu hình thời gian và thực hiện thao tác khôi phục trực tiếp thông qua FPT Console Portal. Lưu ý: Point-in-Time Recovery (PITR) chỉ khả dụng sau khi tính năng được bật, hệ thống hoàn tất bản Full Backup đầu tiên và ghi nhận transaction log kể từ thời điểm đó để phục vụ khôi phục. Khả năng khôi phục phụ thuộc vào thời gian lưu trữ (Retention Period) được cấu hình. Hỗ trợ OpenSearch Version 3.5.0: Mở rộng khả năng tìm kiếm và phân tích FPT Database Engine bổ sung OpenSearch version 3.5.0 vào danh mục hỗ trợ, cho phép người dùng lựa chọn trực tiếp phiên bản này khi khởi tạo OpenSearch cluster trên FPT DBaaS Portal. Phiên bản mới hỗ trợ triển khai theo hai mô hình Single-node và Dedicated Node Architecture. Trong đó, Dedicated Node Architecture cho phép tách biệt các thành phần Cluster Manager Node, Data Node và Coordinator Node, phù hợp với các nhu cầu triển khai OpenSearch cluster khác nhau. Việc hỗ trợ OpenSearch 3.5.0 giúp doanh nghiệp nhanh chóng tiếp cận các tính năng, cải tiến và bản vá bảo mật mới nhất, đồng thời linh hoạt lựa chọn mô hình triển khai phù hợp với nhu cầu thực tế. Bên cạnh đó, toàn bộ quá trình triển khai và quản lý OpenSearch cluster đều được thực hiện tập trung trên FPT DBaaS Portal, giúp tối ưu hóa hiệu quả vận hành. Lưu ý: Để sử dụng OpenSearch version 3.5.0, người dùng cần khởi tạo một cluster mới và thực hiện migrate dữ liệu. Các OpenSearch cluster hiện tại không tự động nâng cấp lên phiên bản này. FPT khuyến nghị bật Backup trước khi thực hiện migrate để đảm bảo an toàn dữ liệu.  Bằng việc liên tục bổ sung các tính năng cao cấp, FPT Database Engine một lần nữa khẳng định cam kết mang đến một hạ tầng dữ liệu An toàn - Hiệu suất - Đơn giản hóa vận hành cho mọi doanh nghiệp.  Liên hệ với chúng tôi để được tư vấn chi tiết về các giải pháp, dịch vụ của FPT Cloud:    Hotline: 1800 6139   Email: support@fptcloud.com   Support: m.me/fptsmartcloud 

Thị trường chứng khoán Việt Nam đang bước vào giai đoạn cạnh tranh mới, khi phí giao dịch hay chất lượng môi giới không còn là yếu tố quyết định. FTSE Russell đã xác nhận nâng hạng thị trường lên nhóm Mới nổi Thứ cấp, hiệu lực từ ngày 21/9/2026, Áp lực với các công ty chứng khoán chuyển sang năng lực hạ tầng số, khai thác dữ liệu và mức độ sẵn sàng đưa AI vào vận hành thực tế. Hệ giải pháp AI do Chứng khoán DNSE tự phát triển là một ví dụ cụ thể về việc AI đã đi vào giao dịch hàng ngày của nhà đầu tư như thế nào, và cần nền tảng gì để vận hành an toàn. Tự chủ công nghệ để làm chủ trải nghiệm giao dịch  Thay vì mua giải pháp có sẵn từ bên thứ ba, DNSE chọn hướng tự chủ công nghệ. Toàn bộ nền tảng giao dịch và các sản phẩm AI đều do đội ngũ kỹ sư của công ty thiết kế, phát triển và vận hành. Hệ giải pháp gồm hai sản phẩm nhà đầu tư dùng trực tiếp, đứng trên một lớp nền tảng dữ liệu chung. Lệnh AI là tính năng đặt lệnh ứng dụng mô hình AI trên ứng dụng giao dịch Entrade X. Khi nhà đầu tư cần mua hoặc bán khối lượng lớn, hệ thống liên tục thu thập và phân tích giá, khối lượng, biến động thị trường để xác định chiến lược phân bổ lệnh. AI sau đó tự động chia lệnh lớn thành các lệnh con, tối thiểu mỗi phút một lệnh, với khối lượng từng lệnh do mô hình quyết định. Thời gian chạy tối đa 180 phút trong phiên khớp lệnh liên tục. Lệnh con được tự động hủy nếu mô hình đánh giá điều kiện thị trường không còn phù hợp. Cơ chế này tương đồng với các thuật toán thực thi lệnh (execution algorithm) mà nhà đầu tư tổ chức quốc tế vẫn dùng để giảm tác động thị trường của lệnh lớn, nay được đóng gói cho nhà đầu tư cá nhân. Trợ lý ảo Ensa là trợ lý chứng khoán ứng dụng AI dưới hình thức chatbot, hỗ trợ nhà đầu tư tra cứu và phân tích dữ liệu trong quá trình ra quyết định. Ensa từng được vinh danh "Giải pháp AI đột phá lĩnh vực tài chính" tại AI Awards 2024. Bên dưới hai sản phẩm là hạ tầng do DNSE tự xây theo kiến trúc microservices, vận hành trên nền tảng điện toán đám mây của FPT Cloud: hệ thống được phân tán để tránh điểm nghẽn trung tâm, không để một database gánh mọi loại workload. Theo công bố của công ty, kiến trúc này giúp độ trễ xử lý lệnh giữ ổn định ở mức khoảng 5 mili giây khi khối lượng lệnh tăng gấp 10 lần. Hiệu quả vận hành và giá trị thực tiễn cho nhà đầu tư Giải pháp đã vượt qua giai đoạn thử nghiệm. Sau khoảng 1 năm chính thức ra mắt, tính tới tới hết Quý 2/2026, Lệnh AI đã thu hút gần 12.000 người dùng đăng ký sử dụng, với tổng giá trị giao dịch đạt 665 tỷ đồng. Với Trợ lý ảo Ensa, sau hơn 1 năm ra mắt, khoảng 1,8 triệu câu hỏi của nhà đầu tư đã được xử lý, bình quân gần 3.300 câu hỏi mỗi ngày, phục vụ hơn 91.000 người dùng. Với nhà đầu tư, giá trị của Trợ lý ảo Ensa là cung cấp trải nghiệm tư vấn đầu tư toàn diện, chủ động trò chuyện, gợi mở thông tin giải pháp cho nhà đầu tư chủ động. Còn Lệnh AI mang đến 3 lợi ích giúp tối ưu quá trình đặt lệnh. Lệnh khối lượng lớn được chia nhỏ theo diễn biến thị trường, giảm rủi ro tự đẩy giá bất lợi và tối ưu giá khớp bình quân. Máy giám sát thị trường thay con người, nhà đầu tư bớt áp lực theo dõi bảng điện liên tục và giảm yếu tố cảm xúc khi quyết định. Việc AI trực tiếp đặt lệnh cũng giúp bảo mật chiến lược giao dịch, tránh bị đọc vị ý định mua bán khối lượng lớn. Ở tầm thị trường, ý nghĩa của hướng đi này rộng hơn một tính năng. Công cụ thực thi lệnh thông minh vốn là đặc quyền của nhà đầu tư tổ chức đang được phổ cập cho nhà đầu tư cá nhân, đúng thời điểm thị trường Việt Nam chuẩn bị vận hành theo chuẩn mực mới nổi từ tháng 9/2026 và đón dòng vốn tổ chức quốc tế vốn đòi hỏi hạ tầng giao dịch ổn định, minh bạch hơn. Nền dữ liệu phải vững trước khi AI mở rộng AI đã đi vào sản phẩm khách hàng dùng hàng ngày và trực tiếp hành động trên dữ liệu vận hành thật. Vì vậy, DNSE xác định củng cố hạ tầng và nền tảng dữ liệu là trọng tâm đầu tư tiếp theo. Chia sẻ tại sự kiện Modern Architecture for the AI Era do FPT tổ chức, ông Nguyễn Đức Bình, Giám đốc Công nghệ DNSE, cho biết trước khi mở rộng quy mô ứng dụng AI, công ty đã rà soát và xử lý ba nhóm rủi ro dữ liệu. Một là, cùng một khái niệm có thể mang nghĩa khác nhau tùy hệ thống. Trạng thái "Active" của khách hàng được CRM, Core Trading và hệ thống quản trị rủi ro hiểu theo ba cách khác nhau. AI đọc cả ba nguồn cùng lúc mà thiếu phản xạ đối chiếu sẽ nhận định sai. DNSE đang thống nhất định nghĩa cho từng thuật ngữ xuyên suốt các hệ thống, gán rõ chủ sở hữu định nghĩa và cơ chế cập nhật khi nghiệp vụ thay đổi. Hai là, AI Agent có thể tiếp cận dữ liệu vượt phạm vi quyền hạn của người hỏi. Đội ngũ công nghệ chuyển từ kiểm tra quyền một lần ở cổng vào sang theo dõi quyền hạn xuyên suốt quá trình xử lý, kèm bước kiểm tra lại kết quả đầu ra trước khi trả về người dùng. Ba là, cấu trúc dữ liệu (schema) có thể âm thầm thay đổi trong vận hành mà mô hình không được cập nhật, khiến AI suy luận trên nền dữ liệu đã sai lệch. Theo ông Bình, đây là điều đáng lo hơn một lỗi hiển nhiên, vì không ai nhận ra cho đến khi hậu quả xuất hiện. Audit trail (dấu vết kiểm toán) vì thế được đưa vào như yêu cầu thiết kế ngay từ đầu. Diễn tập phục hồi backup và kiểm soát thay đổi schema trở thành bước bắt buộc trước khi bất kỳ hệ thống AI nào chạy thật. Phần lớn nguyên tắc kiến trúc đứng sau những thay đổi này đều không mới. Chúng là những nguyên tắc tốt đã tồn tại từ trước, nhưng khi triển khai AI thì chuyển từ khuyến nghị thành bắt buộc, ông Bình nhận định. Cách tiếp cận này khớp với bức tranh quốc tế: khảo sát của KPMG trên 1.013 lãnh đạo tài chính tại 20 quốc gia cho thấy 36% tổ chức xem chất lượng dữ liệu vừa là rào cản lớn nhất vừa là cơ hội lớn nhất của AI trong tài chính. Khi trọng tâm cạnh tranh của ngành chuyển từ phí giao dịch sang năng lực công nghệ và dữ liệu, giá trị của một giải pháp AI không chỉ nằm ở tính năng nhà đầu tư nhìn thấy. Nó nằm ở nền tảng bảo đảm những quyết định tự động luôn chính xác và trong đúng phạm vi cho phép. Như ông Bình đúc kết: "AI không tạo ra những vấn đề. Nó chỉ khiến ta không còn giấu được chúng." Hệ sinh thái AI-ready Data Platform của FPT Cloud Những bài học từ DNSE cũng là điều FPT Cloud quan sát khi đồng hành cùng nhiều doanh nghiệp trong hành trình triển khai AI. Dù ở lĩnh vực tài chính, bán lẻ hay sản xuất, điểm chung đều không nằm ở việc lựa chọn mô hình AI nào, mà ở việc doanh nghiệp có một nền tảng dữ liệu đủ tin cậy để AI vận hành an toàn hay không. Một nền tảng dữ liệu sẵn sàng cho AI thường được tổ chức theo ba lớp độc lập nhưng liên kết chặt chẽ, lớp vận hành thời gian thực phục vụ đa nguồn dữ liệu, lớp phân tích và báo cáo tách riêng để không cạnh tranh tài nguyên với lớp vận hành, và lớp trí tuệ nhân tạo được xây dựng trên nền tảng dữ liệu hợp nhất để huấn luyện mô hình. Một hệ thống AI không thất bại vì mô hình kém, mà thường thất bại vì hạ tầng dữ liệu phía dưới chưa phù hợp. Đây cũng là cách FPT Cloud thiết kế hệ sinh thái AI-Ready Data Platform của mình, kết nối từ lớp hạ tầng điện toán (GPU, Cloud Server, lưu trữ), qua lớp nền tảng dữ liệu (thu thập, xử lý, lưu trữ với nhiều loại database engine phù hợp từng bài toán), đến lớp bảo mật và quản trị dữ liệu xuyên suốt toàn bộ vòng đời. Trong lớp nền tảng dữ liệu đó, FPT MongoDB Enterprise là dịch vụ cơ sở dữ liệu quản lý (DBaaS) đầu tiên tại Việt Nam được MongoDB chính thức chứng nhận, phù hợp cho các workload cần mô hình dữ liệu linh hoạt và khả năng mở rộng theo chiều ngang, một trong những đặc tính then chốt để một nền tảng dữ liệu thực sự sẵn sàng cho AI. Liên hệ với chúng tôi để được tư vấn chi tiết về dịch vụ của FPT MongoDB Enterprise Email: support@fptcloud.com Support: m.me/fptsmartcloud

Chương trình phát triển công nghiệp công nghệ số giai đoạn 2026–2030 (Quyết định 840/QĐ-TTg) đặt mục tiêu doanh thu ngành đạt tối thiểu 300 tỷ USD trên tinh thần “Make in Viet Nam" xuyên suốt. Chương trình mở ra đúng lúc doanh nghiệp Việt đứng trước các quy định mới về dữ liệu, AI, đưa AI vào vận hành và kiểm soát chi phí, bảo vệ tài sản số - bài toán khó giải bằng cách thức truyền thống.  FPT Cloud, hạ tầng số Make in Viet Nam do kỹ sư Việt làm chủ trên chuẩn mở quốc tế, là lời giải cho cả ba trong cùng một quyết định hạ tầng, đồng nhịp với mục tiêu quốc gia.  Hạ tầng là điểm thực thi của mọi yêu cầu về dữ liệu và AI  Từ năm 2026, khung pháp lý mới của Việt Nam về bảo vệ dữ liệu cá nhân, an ninh mạng² và trí tuệ nhân tạo³ cùng đặt ra các yêu cầu về nơi dữ liệu lưu trú, việc chuyển dữ liệu xuyên biên giới, và khả năng giám sát, can thiệp của con người đối với hệ thống AI. Tại thị trường thế giới, theo McKinsey có gần ba phần tư doanh nghiệp đã đưa AI chủ quyền (sovereign AI) vào lộ trình công nghệ năm 2026, dù phần lớn vẫn đang ở giai đoạn xây dựng kế hoạch triển khai1, phản ánh việc quyền kiểm soát dữ liệu, hạ tầng và AI đang trở thành một tiêu chí chiến lược trên quy mô toàn cầu.  Điểm thực thi của tất cả quy định về dữ liệu và AI đều nằm ở hạ tầng vận hành doanh nghiệp. Vị trí lưu trú của dữ liệu được quyết định bởi kiến trúc lưu trữ và vùng triển khai (region), không phải bởi ứng dụng. Quyền truy cập được thực thi ở các lớp định danh, mạng và ảo hóa, nơi mọi yêu cầu đều phải được xác thực trước khi tới ứng dụng. Nhật ký kiểm toán chỉ có giá trị chứng minh khi được ghi nhận ở tầng hạ tầng, nơi đối tượng bị giám sát không thể tự sửa đổi bản ghi. Tương tự, các cơ chế kiểm soát AI như dừng xử lý, thu hồi tài nguyên tính toán hay ngắt luồng dữ liệu đều được thực hiện thông qua lớp điều phối hạ tầng. Đối với doanh nghiệp, năng lực làm chủ hạ tầng là điều kiện để làm chủ công nghệ.  Hạ tầng số nền mở "Make in Viet Nam" - điều kiện để làm chủ công nghệ và củng cố chủ quyền số  Làm chủ hạ tầng số bao gồm ba cấp độ: vận hành hệ thống; tùy biến, tối ưu hệ thống; và cao nhất là can thiệp vào tầng lõi, sửa chính mã nguồn đang chạy. Ở cấp độ này, nền tảng mã nguồn mở như OpenStack không tự động tạo ra chủ quyền số, nhưng là điều kiện để doanh nghiệp và đội ngũ kỹ sư trong nước đạt được mức tự chủ công nghệ cao nhất. Khi mã nguồn có thể được kiểm chứng, tùy biến và tối ưu, năng lực kỹ thuật không còn phụ thuộc hoàn toàn vào lộ trình phát triển hay quyền cấp phép của một nhà cung cấp độc quyền.  FPT Cloud được xây dựng trên nền tảng mã nguồn mở OpenStack, do đội ngũ kỹ sư Việt Nam vận hành và tối ưu đến tầng lõi. Ảnh: FPT Cloud OpenStack hiện là một trong những nền tảng hạ tảng mã nguồn mở được triển khai rộng rãi trong các môi trường đám mây riêng (private cloud) và đám mây viễn thông (telco cloud) quy mô lớn. Đây cũng là nền tảng được nhiều nhà cung cấp dịch vụ hạ tầng lựa chọn khi xây dựng các mô hình đám mây chủ quyền (sovereign cloud) nhờ khả năng kiểm chứng và tùy biến đến tầng lõi. Chính khả năng này giúp doanh nghiệp duy trì quyền kiểm soát đối với hạ tầng mà không bị khóa chặt vào một hệ sinh thái độc quyền. Chuẩn mở không loại bỏ hoàn toàn chi phí chuyển đổi, nhưng giúp chi phí đó trở nên hữu hạn và có thể dự báo, qua đó duy trì quyền thương lượng của khách hàng trong dài hạn. Theo hướng đó, FPT Cloud lựa chọn xây dựng hạ tầng trên nền tảng mã nguồn mở OpenStack, để các doanh nghiệp có thể sử dụng một nền tảng do đội ngũ kỹ sư trong nước làm chủ và vận hành, song song đó vẫn kế thừa các tiêu chuẩn mở đã được kiểm chứng trên phạm vi toàn cầu.  Tự chủ công nghệ tạo ra quyền kiểm soát, quyền thương lượng và lợi ích kinh tế dài hạn  Với doanh nghiệp, giá trị kinh tế của tự chủ công nghệ trước hết nằm ở quyền kiểm soát. Khi dịch vụ được cung cấp thông qua hợp đồng trong nước, doanh nghiệp giảm mức độ phụ thuộc trực tiếp vào biến động tỷ giá và chính sách giá từ các thị trường bên ngoài. Dữ liệu và khối lượng công việc được triển khai trên các chuẩn mở giúp duy trì khả năng dịch chuyển giữa các môi trường hạ tầng. Khi chi phí chuyển đổi trở nên hữu hạn và có thể dự báo, quyền thương lượng không còn nằm hoàn toàn ở nhà cung cấp mà quay trở lại với doanh nghiệp sử dụng. Ý nghĩa của tự chủ công nghệ trong kỷ nguyên AI tạo ra lợi ích kinh tế dài hạn cho doanh nghiệp.  Một ví dụ là Ahamove, nền tảng giao vận có hơn 20.000 tài xế hoạt động đồng thời mỗi ngày. Với đặc thù lưu lượng có thể tăng hơn 200% trong các khung giờ cao điểm, bài toán của doanh nghiệp không đơn thuần là mở rộng tài nguyên, mà là duy trì khả năng mở rộng theo nhu cầu thực tế mà không làm gián đoạn dịch vụ.  Sau khi chuyển đổi lên FPT Cloud, doanh nghiệp hợp nhất hạ tầng trên một nền tảng Cloud Serrver duy nhất, áp dụng cơ chế tự động mở rộng (auto scaling) theo lưu lượng thực tế và đạt SLA 99,99% cho hệ thống mới. Theo số liệu công bố từ doanh nghiệp, việc tối ưu hạ tầng giúp giảm tới 30% chi phí vận hành, đồng thời duy trì độ trễ xử lý dưới 200 ms ngay cả khi lưu lượng tăng đột biến.  Trường hợp này cho thấy giá trị của một hạ tầng Make in Viet Nam không chỉ nằm ở nơi dữ liệu được lưu trữ, mà ở khả năng kết hợp giữa năng lực vận hành trong nước, kiến trúc mở và khả năng mở rộng linh hoạt để giải quyết đồng thời các yêu cầu về hiệu năng, chi phí và tính liên tục của dịch vụ.  Chủ quyền số được củng cố khi doanh nghiệp có năng lực làm chủ toàn bộ chuỗi vận hành  Tự chủ công nghệ của doanh nghiệp góp phần củng cố chủ quyền số khi doanh nghiệp có năng lực làm chủ toàn bộ chuỗi vận hành, kết hợp đồng thời bốn yếu tố: hạ tầng triển khai tại Việt Nam, dữ liệu thuộc phạm vi điều chỉnh của pháp luật Việt Nam, đội ngũ kỹ sư trong nước trực tiếp vận hành và làm chủ công nghệ, cùng năng lực đã được kiểm chứng qua triển khai thực tế ở quy mô lớn. Đây mới là những yếu tố quyết định khả năng bảo vệ dữ liệu, duy trì tính liên tục của dịch vụ và bảo đảm doanh nghiệp luôn giữ được quyền kiểm soát đối với tài sản số của mình.  FPT Cloud được xây dựng trên nền tảng mã nguồn mở OpenStack với đội ngũ chuyên gia Việt Nam tham gia đóng góp cho cộng đồng OpenInfra toàn cầu và có khả năng tối ưu đến tầng lõi. Hệ thống được triển khai trên các trung tâm dữ liệu tại Việt Nam, đáp ứng mọi quy định của pháp luật Việt Nam. FPT Cloud hiện phục vụ hơn 3.000 khách hàng với hơn 80 dịch vụ cloud, dữ liệu và AI. Quy mô triển khai này phản ánh năng lực vận hành hạ tầng trong môi trường sản xuất thực tế ở nhiều lĩnh vực, đồng thời tạo nền tảng để tích lũy kinh nghiệm tối ưu hệ thống và bảo đảm tính liên tục của dịch vụ ở quy mô lớn.  Trong kỷ nguyên AI, lợi thế cạnh tranh của doanh nghiệp không còn chỉ đến từ việc tiếp cận công nghệ tiên tiến, mà từ khả năng kiểm soát công nghệ đó trong suốt vòng đời vận hành. Theo tinh thần Quyết định 840, "Make in Viet Nam" vì vậy không phải là thay thế công nghệ toàn cầu, mà là làm chủ những năng lực cốt lõi để doanh nghiệp Việt hợp tác với thế giới từ một vị thế chủ động.  Liên hệ với chúng tôi để được tư vấn chi tiết về các giải pháp, dịch vụ của FPT Cloud: Hotline: 1900 638 399 Email: support@fptcloud.com Support: m.me/fptsmartcloud

Trong kỷ nguyên số, dữ liệu của doanh nghiệp không ngừng mở rộng và phân tán trên nhiều hệ thống phức tạp. Thách thức đặt ra là làm thế nào để kiểm soát quyền truy cập chặt chẽ, bảo vệ toàn diện các lớp dữ liệu nhạy cảm, đồng thời đáp ứng trọn vẹn các yêu cầu kiểm toán nghiêm ngặt. Phiên bản FPT Data Governance & Security v1.1.3 chính thức ra mắt nhằm giải quyết triệt để bài toán này, mang đến giải pháp chuẩn hóa quản trị danh tính và an toàn dữ liệu tập trung trên môi trường Big Data. FPT Data Governance & Security v1.1.3 có gì mới?  Phiên bản 1.1.3 tập trung chuẩn hóa hoạt động quản trị truy cập dữ liệu trên một nền tảng tập trung, đồng thời tăng cường khả năng bảo vệ dữ liệu nhạy cảm và hỗ trợ doanh nghiệp đáp ứng tốt hơn các yêu cầu kiểm toán, tuân thủ. Điểm nổi bật của phiên bản này là khả năng tích hợp SSO, cho phép người dùng truy cập FPT Data Governance & Security bằng tài khoản doanh nghiệp hiện có. Nhờ đó, doanh nghiệp có thể giảm nhu cầu quản lý tài khoản rời rạc, đơn giản hóa trải nghiệm đăng nhập và tăng tính nhất quán trong toàn bộ hệ sinh thái dữ liệu. Khi kết hợp với LDAP User Sync, hệ thống có thể đồng bộ định danh, nhóm người dùng và vai trò theo mô hình tổ chức hiện hữu. Điều này giúp doanh nghiệp chuẩn hóa quản trị danh tính, đơn giản hóa quy trình phân quyền và hạn chế rủi ro từ các quyền truy cập không còn phù hợp. Những cập nhật mới trong FPT Data Governance & Security v1.1.3  2.1. Quản lý chính sách truy cập tập trung  FPT Data Governance & Security cung cấp một điểm quản trị tập trung để cấu hình chính sách truy cập cho nhiều dịch vụ dữ liệu khác nhau. Thay vì phải quản lý quyền rời rạc trên từng hệ thống, quản trị viên có thể thiết lập và rà soát chính sách trên một lớp quản trị thống nhất. Các chính sách truy cập có thể được định nghĩa chi tiết theo người dùng, nhóm người dùng, vai trò, tài nguyên dữ liệu, bảng, cột, thư mục, tệp hoặc topic. Cách tiếp cận này giúp doanh nghiệp kiểm soát quyền truy cập linh hoạt hơn, đồng thời bảo đảm mỗi nhóm người dùng chỉ được sử dụng dữ liệu đúng theo phạm vi được cấp quyền. Về mặt vận hành, quản lý chính sách tập trung giúp giảm thao tác phân quyền thủ công, hạn chế rủi ro cấu hình không nhất quán và hỗ trợ chuẩn hóa quy trình cấp quyền, thu hồi quyền, rà soát quyền truy cập theo từng nhóm nghiệp vụ hoặc lớp dữ liệu. 2.2. Hỗ trợ kiểm soát truy cập chi tiết  FPT Data Governance & Security v1.1.3 hỗ trợ nhiều cơ chế kiểm soát truy cập ở các cấp độ khác nhau, giúp doanh nghiệp bảo vệ dữ liệu nhạy cảm trong quá trình khai thác và phân tích. RBAC (Role-Based Access Control): Kiểm soát truy cập theo vai trò và cơ cấu tổ chức. Đồng bộ linh hoạt qua LDAP và SSO giúp giảm lỗi thao tác thủ công, tăng tốc quy trình tiếp nhận (onboarding) và thu hồi quyền (offboarding) nhân sự. ABAC (Attribute-Based Access Control): Thiết lập chính sách linh hoạt dựa trên thuộc tính, ngữ cảnh, metadata hoặc tag dữ liệu. Phù hợp với mô hình phân loại dữ liệu hiện đại, đặc biệt hiệu quả khi bảo vệ dữ liệu nhạy cảm, dữ liệu tài chính, khách hàng hay dữ liệu nội bộ. Row-Level Filtering: Lọc dữ liệu mức dòng. Cho phép nhiều nhóm người dùng khai thác chung một tập dữ liệu (bảng), nhưng mỗi nhóm chỉ được phép nhìn thấy phần dữ liệu thuộc phạm vi thẩm quyền của mình. Column-Level Filtering: Lọc dữ liệu mức cột. Ẩn hoặc giới hạn quyền truy cập đến các cột chứa dữ liệu nhạy cảm (như thông tin định danh cá nhân, thẻ tín dụng...), bảo vệ thông tin cần kiểm soát đặc biệt. 2.3. Kiểm toán và giám sát truy cập dữ liệu  FPT Data Governance & Security v1.1.3 hỗ trợ ghi lại hoạt động truy cập dữ liệu với các thông tin quan trọng như người dùng hoặc ứng dụng truy cập, thời gian truy cập, tài nguyên được truy cập, loại hành động và kết quả truy cập. Dữ liệu kiểm toán có thể được xuất sang hệ thống bên ngoài để phục vụ phân tích, báo cáo, lưu trữ dài hạn hoặc tích hợp với công cụ giám sát bảo mật. Nhờ đó, doanh nghiệp có thêm cơ sở để truy vết sự cố, đánh giá mức độ tuân thủ và chuẩn bị bằng chứng cho các đợt kiểm toán. 2.4. Hỗ trợ đa nền tảng trong hệ sinh thái dữ liệu lớn  FPT Data Governance & Security v1.1.3 hỗ trợ tích hợp với nhiều thành phần dữ liệu và xử lý dữ liệu, giúp doanh nghiệp áp dụng một lớp kiểm soát truy cập nhất quán trên toàn bộ data platform. Các thành phần được hỗ trợ gồm: Thành phần  Phạm vi kiểm soát HDFS Quản lý quyền truy cập tệp và thư mục Hive Kiểm soát truy cập đến database, bảng, cột và các đối tượng ữ liệu phục vụ phân tích HBase  Quản lý quyền truy cập đến bảng, hàng dữ liệu và các đối tượng dữ liệu theo phạm vi được cấp quyền Kafka Kiểm soát quyền truy cập đến topic, hỗ trợ quản trị dữ liệu streaming và event-driven workload. Storm  Quản lý quyền truy cập đến topology phục vụ xử lý luồng dữ liệu YARN Kiểm soát quyền truy cập đến tài nguyên cluster, hỗ trợ vận hành workload xử lý dữ liệu an toàn hơn Việc mở rộng phạm vi tích hợp giúp doanh nghiệp giảm tình trạng phân mảnh trong kiểm soát dữ liệu. Thay vì áp dụng nhiều cơ chế quản trị riêng lẻ cho từng thành phần, đội ngũ vận hành có thể quản lý quyền truy cập theo một lớp chính sách thống nhất hơn.  2.5. Hỗ trợ tuân thủ và bảo mật  FPT Data Governance & Security v1.1.3 hỗ trợ khách hàng thiết lập nền tảng kiểm soát truy cập và kiểm toán chi tiết, phục vụ các yêu cầu về tuân thủ như GDPR, HIPAA, PCI-DSS hoặc các quy định nội bộ của doanh nghiệp. Thông qua việc kết hợp phân quyền chi tiết, phân loại dữ liệu bằng metadata/tag và audit log, doanh nghiệp có thể tăng mức độ minh bạch trong quản trị dữ liệu, đồng thời chuẩn bị tốt hơn cho các hoạt động kiểm toán và rà soát bảo mật. Lưu ý, mức độ đáp ứng tuân thủ thực tế vẫn phụ thuộc vào cách doanh nghiệp thiết kế chính sách, vận hành quy trình và cấu hình lưu trữ dữ liệu kiểm toán. FPT Data Governance & Security đóng vai trò là công cụ hỗ trợ quản trị quyền truy cập và kiểm toán, giúp doanh nghiệp có nền tảng rõ ràng hơn để xây dựng năng lực tuân thủ trong môi trường dữ liệu lớn. FPT Data Governance & Security v1.1.3 là bước cập nhật quan trọng trong việc hoàn thiện lớp quản trị dữ liệu tập trung cho doanh nghiệp. Với khả năng tích hợp SSO, quản lý chính sách truy cập tập trung, kiểm soát chi tiết theo nhiều cấp độ và hỗ trợ kiểm toán, phiên bản mới giúp doanh nghiệp bảo đảm dữ liệu được truy cập đúng người, đúng quyền và đúng phạm vi, từ đó xây dựng môi trường dữ liệu lớn an toàn, minh bạch và sẵn sàng đáp ứng các yêu cầu tuân thủ. Tìm hiểu về giải pháp FPT Data Governance & Security tại đây Liên hệ với chúng tôi để được tư vấn chi tiết về các giải pháp, dịch vụ của FPT Cloud:  Hotline: 1900 638 399 Email: support@fptcloud.com Support: m.me/fptsmartcloud