Chính phủ nền tảng số (Digital Platform Government)

1. Tổng quan

A. Định nghĩa

Mô hình đổi mới chính phủ — đồng thời là mô thức vận hành chính phủ — tích hợp toàn bộ dữ liệu và dịch vụ của chính phủ trên một nền tảng số duy nhất, để người dân·doanh nghiệp·chính phủ cùng giải quyết các vấn đề xã hội và tạo ra giá trị mới, chuyển chính phủ từ 'nhà cung cấp dịch vụ' thành 'nhà vận hành nền tảng·người mở dữ liệu'.

Ý tưởng cốt lõi của chính phủ nền tảng số (DPG) là chuyển chính phủ từ 'nhà cung cấp dịch vụ (Service Provider)' thành 'nhà vận hành nền tảng (Platform Operator)'. Nếu chính phủ điện tử (e-Government) trước đây để mỗi bộ ngành tự xây dựng hệ thống riêng khiến người dân phải đi qua nhiều trang web, thì chính phủ nền tảng số tập hợp dữ liệu và dịch vụ vào một nền tảng logic và mở ra để khu vực tư nhân có thể tạo dịch vụ đổi mới trên đó. Giống như kho ứng dụng của điện thoại thông minh, đây là cấu trúc trong đó chính phủ mở dữ liệu·chức năng qua API chuẩn, còn khu vực tư nhân kết hợp chúng để tạo dịch vụ tùy biến mà người dân mong muốn.

Ý nghĩa của sự chuyển đổi này không phải là tích hợp hệ thống đơn thuần mà nằm ở chỗ thay đổi chính nguyên lý vận hành của hành chính. Chính phủ điện tử hiện có dựa trên 'nguyên tắc nộp đơn', tức người dân phải biết mình đủ điều kiện và tự tìm đến nộp đơn mới nhận được dịch vụ. Ngược lại, DPG chia sẻ·liên kết dữ liệu giữa các bộ ngành, nhờ đó chính phủ nhận biết trước thay đổi hoàn cảnh của người dân (sinh con·mất việc·thiên tai...) và chủ động (Proactive) đề xuất·cung cấp dịch vụ. Người dân giải quyết mọi việc tại một nơi mà không cần đến nhiều cơ quan (một cửa), còn chính phủ vượt qua vách ngăn giữa các bộ ngành để chia sẻ dữ liệu và hiện thực hành chính khoa học·tùy biến.

B. Bối cảnh ra đời và sự cần thiết

Đằng sau sự nổi lên của DPG là ba áp lực mang tính cấu trúc chồng lên nhau. Thứ nhất, sự đứt gãy dịch vụ do silo theo bộ ngành. Lâu nay mỗi bộ ngành·chính quyền địa phương tự xây dựng hệ thống thông tin riêng, dữ liệu bị giam trong ranh giới cơ quan, khiến người dân phải nộp lặp lại cùng một giấy tờ cho nhiều cơ quan và hành chính phối hợp liên ngành gần như bất khả thi. Thứ hai, kỳ vọng về trải nghiệm số của người dân tăng cao. Người dân bắt đầu đòi hỏi ở dịch vụ công mức siêu cá nhân hóa·tức thời mà các nền tảng tư nhân (tài chính·mua sắm·di chuyển) cung cấp. Thứ ba, sự chín muồi của công nghệ dữ liệu·AI·cloud. Khi liên kết dữ liệu quy mô lớn, tư vấn dựa trên AI tạo sinh, mở rộng cloud-native trở nên khả thi về kỹ thuật, nền tảng để thực sự hiện thực một chính phủ tích hợp·mở đã được thiết lập.

Trường hợp Hàn Quốc, dù đã duy trì lâu dài chính phủ điện tử ở trình độ hàng đầu thế giới (nhóm dẫn đầu trong đánh giá chính phủ điện tử của Liên Hợp Quốc), vẫn bị chỉ ra hạn chế là sự ưu việt của từng hệ thống riêng lẻ không chuyển hóa được thành 'trải nghiệm tích hợp mà người dân cảm nhận được'. DPG có thể được hiểu là nỗ lực cấp quốc gia nhằm lấp khoảng trống này bằng kiến trúc tích hợp·mở lấy dữ liệu làm trung tâm.

2. Cấu trúc tổng thể và thành phần

Chính phủ nền tảng số có thể được xem như cấu trúc đa tầng trong đó tầng dữ liệu, tầng mở·liên kết, tầng dịch vụ, tầng hạ tầng xếp chồng theo chiều dọc. Sơ đồ khái niệm dưới đây thể hiện cấu trúc tổng thể này.

flowchart TB
  subgraph SVC["Tầng dịch vụ"]
    S1["Cửa tích hợp một cửa (Government24...)"]
    S2["Dịch vụ kết hợp ứng dụng tư nhân"]
    S3["Dịch vụ chủ động·tùy biến"]
  end
  subgraph OPEN["Tầng mở·liên kết"]
    O1["Mở API công"]
    O2["Chuẩn·liên kết dữ liệu (EA/chuẩn chung)"]
    O3["MyData (truyền thông tin cá nhân)"]
  end
  subgraph DATA["Tầng dữ liệu"]
    D1["Dữ liệu hành chính của bộ ngành·địa phương"]
    D2["Dữ liệu mở của Cổng dữ liệu công"]
    D3["Data lake·Nền tảng phân tích"]
  end
  subgraph INFRA["Tầng hạ tầng"]
    I1["Cloud hành chính (tư nhân·công)"]
    I2["Nền tảng AI chung (AI tạo sinh)"]
    I3["Bảo mật Zero Trust"]
  end
  SVC --> OPEN --> DATA --> INFRA
  style SVC fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px

Tầng dữ liệu gồm dữ liệu hành chính phân tán ở các bộ ngành·địa phương, dữ liệu mở của Cổng dữ liệu công (data.go.kr), cùng data lake·nền tảng phân tích tập hợp chúng thành dạng có thể phân tích. Mọi giá trị của DPG rốt cuộc xuất phát từ dữ liệu, nên chất lượng·chuẩn hóa·khả năng liên kết của tầng này quyết định thành bại toàn cục. Nếu dữ liệu không được chuẩn hóa hoặc không thể ra khỏi cơ quan thì các tầng trên không vận hành được.

Tầng mở·liên kết là 'điểm tiếp xúc' giúp bên ngoài sử dụng được dữ liệu và chức năng. Nó mở API công theo cách chuẩn, đồng bộ các mô hình dữ liệu khác nhau của từng cơ quan bằng chuẩn chung·kiến trúc doanh nghiệp (EA), và thông qua MyData (quyền yêu cầu truyền thông tin cá nhân) cho phép người dân chuyển thông tin hành chính của mình đến nơi mong muốn. Tầng này càng dày thì dư địa đổi mới của khu vực tư nhân càng lớn.

Tầng dịch vụ là điểm người dân thực sự tiếp xúc. Xử lý một cửa tại cửa tích hợp như Government24 (Jeongbu24), ứng dụng tư nhân kết hợp API công để tạo dịch vụ mới, và dựa trên phân tích dữ liệu để chủ động thông báo dịch vụ cho người dân đủ điều kiện. Tầng hạ tầng gồm nền tảng cloud-native đỡ toàn bộ các tầng trên, nền tảng AI chung, và bảo mật Zero Trust kiểm soát rủi ro tất yếu gia tăng cùng với việc mở.

3. Nguyên lý cốt lõi — Luồng dữ liệu và quy trình tạo dịch vụ

Quá trình DPG thực sự tạo ra 'dịch vụ tùy biến chủ động' được giải thích như một vòng tuần hoàn trong đó dữ liệu được thu thập·liên kết·phân tích rồi phản hồi thành dịch vụ. Sơ đồ quy trình chi tiết dưới đây thể hiện cách thay đổi hoàn cảnh của người dân dẫn đến dịch vụ.

flowchart LR
  E["Thay đổi hoàn cảnh người dân (sinh con·mất việc...)"] --> C["Liên kết·thu thập dữ liệu bộ ngành"]
  C --> A["Phân tích AI·Xét điều kiện"]
  A --> M["Ghép đối tượng"]
  M --> N["Thông báo·đề xuất chủ động"]
  N --> P["Nộp đơn·xử lý một cửa"]
  P --> F["Phản hồi dữ liệu kết quả"]
  F --> A
  style A fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px

Điểm khởi đầu của luồng này là sự kiện (thay đổi hoàn cảnh). Ví dụ, khi khai sinh được tiếp nhận, sự việc đó được liên kết với dữ liệu của nhiều bộ ngành và 'các hỗ trợ mà gia đình này có thể nhận' được tự động suy ra. Trước đây cha mẹ phải nộp đơn riêng cho trợ cấp sinh con·trợ cấp trẻ em·giảm tiền điện... tại các cơ quan khác nhau, nhưng theo định hướng của DPG, một lần khai báo sẽ kích hoạt toàn bộ dịch vụ liên quan. Thực tế, chính phủ đã mở rộng các dịch vụ gói theo vòng đời như vậy (các dịch vụ một cửa như 'Happy Birth', 'Safe Inheritance'), và DPG hướng tới tự động hóa rộng hơn nữa bằng liên kết dữ liệu.

Ở bước thứ hai phân tích AI·xét điều kiện, dựa vào dữ liệu đã liên kết để phán định người dân có đủ điều kiện thụ hưởng dịch vụ nào. Điều quan trọng ở đây là 'tính chính xác và cập nhật của dữ liệu làm căn cứ phán định'. Nếu thông tin thu nhập·hộ gia đình·cư trú được mỗi bộ ngành quản lý khác nhau thì có thể dẫn đến phán định điều kiện sai, nên chuẩn hóa dữ liệu và quản lý chất lượng quyết định độ tin cậy của bước này.

Bước thứ ba ghép đối tượng·thông báo·xử lý kết nối kết quả phán định với dịch vụ thực tế. Chủ động thông báo (Push) cho đối tượng, và nếu người dân đồng ý thì nộp đơn·xử lý một cửa. Ở bước cuối phản hồi (Feedback), kết quả xử lý lại được tích lũy thành dữ liệu để nâng độ chính xác của lần phân tích tiếp theo. Như vậy, DPG khác căn bản với chính phủ điện tử ở chỗ nó không phải là tin học hóa một lần mà hướng tới cấu trúc tuần hoàn tích cực trong đó dữ liệu sinh ra dịch vụ và dịch vụ lại sinh ra dữ liệu.

4. So sánh với chính phủ điện tử — Lý do tạo ra khác biệt

DPG thường được gọi là 'bước tiếp theo của chính phủ điện tử', nhưng khác biệt giữa hai bên không phải là vấn đề thế hệ công nghệ mà là vấn đề triết lý vận hành. Chính phủ điện tử tập trung vào 'tin học hóa·trực tuyến hóa công việc chính phủ', với mục tiêu cho phép xử lý trên web các thủ tục hành chính vốn làm trực tiếp. Kết quả là mỗi cơ quan tin học hóa tốt công việc của mình, nhưng ranh giới giữa các cơ quan vẫn nguyên vẹn. Ngược lại, DPG tập trung vào 'tích hợp·mở dữ liệu và dịch vụ', với mục tiêu phá bỏ chính ranh giới cơ quan bằng luồng dữ liệu.

Lý do khác biệt này quan trọng trong thực tiễn là muốn tiến tới DPG thì phải thay đổi quản trị và thể chế trước công nghệ. Ví dụ, để bộ B sử dụng dữ liệu của bộ A cần có trước căn cứ theo Luật Bảo vệ thông tin cá nhân, quan hệ sở hữu·trách nhiệm dữ liệu, sự đồng bộ chuẩn. Tức là điểm nghẽn của DPG thường không nằm ở 'hiện thực kỹ thuật' mà ở 'luật·thể chế·chuẩn cho phép chia sẻ dữ liệu'. Nếu không hiểu điểm này thì dù đưa vào cloud·AI tốt đến đâu, kết quả cũng chỉ là thêm một chính phủ điện tử nữa.

Về tình huống cụ thể, dữ liệu được mở qua Cổng dữ liệu công lên tới hàng chục nghìn loại, và khu vực tư nhân đã tận dụng chúng để tạo nhiều ứng dụng về bất động sản·giao thông·thời tiết·khởi nghiệp. Ngoài ra, 'Government24' đã trở thành dịch vụ tích hợp xử lý thủ tục của nhiều cơ quan tại một cửa, và dịch vụ quyết toán thuế cuối năm đơn giản hóa của Hometax (Cục Thuế quốc gia Hàn Quốc) tự động thu thập và cung cấp dữ liệu thu nhập·chi tiêu phân tán, được xem là tình huống tiêu biểu của 'chính phủ thu thập dữ liệu giúp người dân'. Tất cả đều có thể xem là hình thái ban đầu của 'tiện ích cho người dân thông qua liên kết·mở dữ liệu' mà DPG hướng tới.

5. Chuyên sâu — Định hướng triển khai và xu hướng mới nhất

DPG không phải là một hệ thống cụ thể mà là chiến lược quốc gia trung và dài hạn kết hợp nhiều chính sách·chuẩn·hạ tầng, nên xu hướng mới nhất chia thành một số nhánh. Tuy nhiên, lịch trình triển khai chi tiết·quy mô ngân sách có thể thay đổi theo thời điểm, nên ở đây tổng quát hóa và tóm lược theo định hướng.

Thứ nhất, chuyển đổi cloud-native trong hành chính. Cốt lõi là vượt qua việc đơn thuần chuyển các hệ thống cũ của bộ ngành lên cloud (Lift & Shift) để thiết kế lại dựa trên API, chuyển sang cấu trúc trong đó dữ liệu·chức năng có thể gọi lẫn nhau. Trong quá trình này, phân vai giữa cloud công·tư, nới lỏng·điều chỉnh chính sách tách mạng (network separation), và sự đồng bộ với chứng nhận bảo mật cloud (CSAP) trở thành các vấn đề tranh luận.

Thứ hai, gắn AI tạo sinh vào hành chính. Gần đây, các thử nghiệm dạng 'trợ lý·chatbot hành chính AI' — khi người dân hỏi bằng ngôn ngữ tự nhiên thì tìm câu trả lời xuyên qua dịch vụ của nhiều bộ ngành — đang lan rộng. Đây là ứng dụng chỉ khả thi khi việc mở dữ liệu·API của DPG đi trước, tương ứng với bức tranh 'AI hoàn thiện trải nghiệm tích hợp trên nền dữ liệu đã mở'. Tuy nhiên, do vấn đề ảo giác (Hallucination)·quy trách nhiệm của AI tạo sinh, trong lĩnh vực hành chính người ta nhấn mạnh câu trả lời có thể kiểm chứng dựa trên dữ liệu căn cứ (RAG...) và sự xác nhận cuối cùng của con người.

Thứ ba, mở rộng MyData sang khu vực công. Đây là xu hướng mở rộng MyData (quyền yêu cầu truyền thông tin cá nhân) khởi đầu từ ngành tài chính sang hành chính·y tế..., cho phép người dân trực tiếp chuyển thông tin hành chính của mình đến cơ quan·ứng dụng mong muốn để sử dụng. Đây là trục cốt lõi của triết lý mở của DPG ở điểm 'trả lại quyền kiểm soát dữ liệu cho người dân', đồng thời đòi hỏi cơ chế bảo vệ thông tin cá nhân mạnh mẽ.

6. Những điểm cần cân nhắc và hàm ý (Góc độ Kỹ sư chuyên nghiệp)

1. Chuẩn hóa·quản trị dữ liệu là tiền đề thành công. Để liên kết dữ liệu khác nhau của các bộ ngành, trước hết phải có chuẩn dữ liệu, quản lý chất lượng, hệ thống sở hữu·trách nhiệm (data ownership), quản lý dữ liệu tham chiếu·dữ liệu chủ. Mở mà không có quản trị sẽ kết thúc bằng 'một danh sách dữ liệu không kết nối được'. Từ góc độ Kỹ sư chuyên nghiệp, có thể đề xuất EA·kiến trúc dữ liệu và hệ thống quản lý chất lượng dữ liệu là nhiệm vụ tiên quyết của DPG.

2. Cân bằng giữa mở và bảo vệ thông tin cá nhân là then chốt. Càng tích hợp·mở dữ liệu thì rủi ro quyền riêng tư·tái định danh càng lớn. Phải thiết kế cấu trúc 'mở nhưng an toàn' thông qua truyền dữ liệu dựa trên đồng ý bằng MyData, bí danh hóa·ẩn danh hóa, Zero Trust (kiểm chứng cả bên trong), kiểm soát truy cập·log kiểm toán. Chiến lược thực tiễn là thiết kế phân biệt theo mức nhạy cảm của dữ liệu cho sự đánh đổi giữa lợi ích của mở và chi phí của bảo vệ.

3. Cần chuyển đổi legacy và thiết kế lại cloud-native. Không phải di chuyển đơn thuần mà phải thiết kế lại dựa trên microservice·API gateway mới trở thành nền tảng thực sự. Khi đó, để giảm rủi ro xây dựng lại toàn bộ, cần đồng thời chiến lược chuyển đổi dần như mẫu Strangler Fig và kế hoạch chuyển tiếp bảo đảm tính liên tục dịch vụ trong quá trình chuyển đổi.

4. Phải thiết kế tính bền vững của hệ sinh thái hợp tác công-tư. Dù chính phủ mở API, nếu khu vực tư nhân không có động lực tham gia (SLA ổn định, điều khoản sử dụng rõ ràng, mô hình doanh thu) thì hệ sinh thái sẽ không hình thành. Khác biệt quyết định so với chính phủ điện tử là chính phủ được yêu cầu có 'năng lực vận hành nền tảng' bao gồm cả quản lý phiên bản·bảo đảm chất lượng API·hỗ trợ nhà phát triển (cổng nhà phát triển, sandbox).

5. Phải song hành với hòa nhập số (Digital Inclusion). Dịch vụ chủ động·tùy biến càng nâng cao thì người cao tuổi·người khuyết tật·nhóm yếu thế về số càng có nguy cơ bị bỏ lại. Cần duy trì kênh ngoại tuyến·trực tiếp·tư vấn song song với kênh trực tuyến, và đồng thời tuân thủ khả năng tiếp cận (hướng dẫn tiếp cận web) cùng thiết kế dễ sử dụng thì mới trở thành 'nền tảng cho tất cả mọi người'.

Tài liệu tham khảo

• Cổng dữ liệu công (Public Data Portal): https://www.data.go.kr
• Government24: https://www.gov.kr
• Ủy ban Chính phủ nền tảng số (Digital Platform Government Committee): https://www.dpg.go.kr

Tóm tắt một câu: Chính phủ nền tảng số là mô thức tích hợp·mở dữ liệu·dịch vụ của chính phủ trên một nền tảng để công-tư cùng tạo giá trị và hiện thực hành chính chủ động·tùy biến, với thành bại được quyết định bởi chuẩn·quản trị dữ liệu và sự cân bằng với bảo vệ thông tin cá nhân, thiết kế lại cloud-native, và thiết kế hệ sinh thái công-tư bền vững.