Cách đánh giá rủi ro công nghệ giáo dục trước triển khai

Một cách tiếp cận thực tế là xem rủi ro như sự kết hợp giữa khả năng một sự kiện xảy ra và mức độ hậu quả nếu sự kiện xảy ra. Đây cũng là cách NIST diễn giải rủi ro trong AI Risk Management Framework, dựa trên nguyên tắc quản trị rủi ro rộng hơn.

Với công nghệ giáo dục, phạm vi đánh giá phải rộng hơn kiểm tra an ninh mạng. Một nền tảng có thể bảo mật tương đối tốt nhưng vẫn tạo rủi ro nếu thu thập quá nhiều dữ liệu học sinh, làm sai lệch đánh giá học tập, gây bất lợi cho người khuyết tật, phụ thuộc vào nhà cung cấp hoặc khiến trường không thể vận hành khi dịch vụ gián đoạn.

Vì vậy, quyết định triển khai chỉ nên được đưa ra sau khi tổ chức đã xác định được mục tiêu sử dụng, dữ liệu liên quan, nhóm người bị tác động, các kịch bản thất bại, biện pháp kiểm soát và tiêu chí dừng.

Xác định phạm vi trước khi chấm điểm rủi ro

Sai lầm phổ biến là lập một danh sách rủi ro chung cho “phần mềm giáo dục” rồi áp dụng cho mọi sản phẩm. Rủi ro thực tế phụ thuộc rất lớn vào cách công nghệ được sử dụng.

Một ứng dụng chỉ hiển thị nội dung học tập công khai có hồ sơ rủi ro khác hoàn toàn với hệ thống lưu điểm, phân tích hành vi học sinh hoặc sử dụng AI để đề xuất nội dung. Vì vậy, trước khi chấm điểm bất kỳ rủi ro nào, cần mô tả rõ ít nhất bốn yếu tố: mục đích sử dụng, người dùng, dữ liệu và mức độ ảnh hưởng đến quyết định giáo dục.

Ví dụ, cùng một chatbot AI nhưng mức rủi ro thay đổi đáng kể giữa ba trường hợp:

·         Giáo viên dùng để gợi ý câu hỏi thảo luận mà không nhập dữ liệu học sinh

·         Học sinh trực tiếp tương tác với chatbot trong giờ học

·         Chatbot tiếp nhận bài làm, hồ sơ học tập và đưa ra nhận xét dùng để chấm điểm

Trường hợp cuối cần kiểm soát chặt hơn vì công nghệ không chỉ xử lý nhiều dữ liệu hơn mà còn tham gia vào một quyết định có hậu quả đối với người học.

Nếu công nghệ có thành phần AI, cách tiếp cận này tương thích với logic của NIST AI RMF: quản trị rủi ro cần được thực hiện xuyên suốt vòng đời và tổ chức quanh các hoạt động Govern, Map, Measure và Manage, thay vì coi đánh giá là một thủ tục duy nhất trước ngày ra mắt.

Do đó, hồ sơ đánh giá nên ghi rõ:

·         Công nghệ giải quyết vấn đề giáo dục nào

·         Ai bắt buộc sử dụng và ai có thể từ chối

·         Dữ liệu nào được nhập, tạo ra, suy luận hoặc chia sẻ

·         Công nghệ chỉ hỗ trợ hay trực tiếp quyết định kết quả

·         Hậu quả lớn nhất nếu hệ thống sai, ngừng hoạt động hoặc bị lạm dụng

·         Phạm vi thử nghiệm dự kiến và điều kiện để mở rộng triển khai

Phạm vi càng mơ hồ, điểm rủi ro càng ít giá trị vì người đánh giá không biết mình đang đánh giá sản phẩm hay một tình huống sử dụng cụ thể.

Đánh giá rủi ro dữ liệu, quyền riêng tư và an ninh

Dữ liệu là một trong những khu vực cần kiểm tra đầu tiên vì nhiều nền tảng giáo dục xử lý thông tin có khả năng nhận dạng học sinh trực tiếp hoặc gián tiếp. Theo hướng dẫn của Bộ Giáo dục Hoa Kỳ, thông tin nhận dạng cá nhân trong hồ sơ giáo dục có thể bao gồm cả định danh trực tiếp như tên, mã học sinh và các định danh gián tiếp có thể kết hợp để truy ngược một cá nhân.

Không nên chỉ hỏi nhà cung cấp “dữ liệu có được mã hóa không?”. Đánh giá cần đi hết vòng đời dữ liệu.

Kiểm tra dữ liệu nào thực sự cần thiết

Hãy lập bản đồ từ lúc dữ liệu được thu thập đến khi bị xóa:

Thu thập → truyền → lưu trữ → sử dụng → chia sẻ → sao lưu → xóa

Ở mỗi bước cần biết ai có quyền truy cập, mục đích xử lý là gì và dữ liệu tồn tại trong bao lâu.

Một nguyên tắc quan trọng là giảm thiểu dữ liệu: nếu một chức năng không cần ngày sinh, địa chỉ, vị trí, lịch sử hành vi hoặc nội dung trao đổi của học sinh thì không nên thu thập chỉ vì hệ thống có khả năng thu thập.

Đối với dịch vụ dành cho trẻ em, yêu cầu còn nhạy cảm hơn. Hướng dẫn của FTC về COPPA nêu rằng trong một số bối cảnh giáo dục, trường có thể thay mặt phụ huynh đồng ý cho dịch vụ thu thập dữ liệu trẻ em, nhưng quyền đó được giới hạn cho mục đích giáo dục và không mở rộng sang mục đích thương mại khác của nhà cung cấp.

Tương tự, hướng dẫn FERPA của Bộ Giáo dục Hoa Kỳ yêu cầu trong những trường hợp áp dụng ngoại lệ “school official”, bên cung cấp phải chịu sự kiểm soát trực tiếp của trường đối với việc sử dụng và duy trì dữ liệu, đồng thời không được tái sử dụng hay tiết lộ dữ liệu cho mục đích không được phép.

Các quy định cụ thể phụ thuộc quốc gia và loại cơ sở giáo dục, nhưng cơ chế đánh giá không thay đổi: xác định dữ liệu, căn cứ xử lý, mục đích, người nhận và quyền kiểm soát của tổ chức trước khi triển khai.

Đánh giá bảo mật theo khả năng xảy ra sự cố

Một công nghệ có thể gây rủi ro ngay cả khi nhà cung cấp tuyên bố tuân thủ tiêu chuẩn bảo mật. Tổ chức vẫn phải kiểm tra cách công nghệ kết nối với hệ thống của mình.

NIST Cybersecurity Framework 2.0 tổ chức quản trị an ninh mạng thành sáu chức năng: Govern, Identify, Protect, Detect, Respond và Recover. Đây là một khung hữu ích để tránh tình trạng chỉ kiểm tra biện pháp phòng ngừa nhưng bỏ quên phát hiện, ứng phó và phục hồi.

Đối với một nền tảng giáo dục mới, các câu hỏi trọng yếu gồm:

·         Có hỗ trợ xác thực và phân quyền phù hợp không

·         Tài khoản giáo viên, quản trị viên và học sinh được tách quyền như thế nào

·         Nhật ký truy cập có đủ để điều tra sự cố không

·         Nhà cung cấp thông báo vi phạm dữ liệu theo quy trình nào

·         Dữ liệu sao lưu được bảo vệ ra sao

·         Trường có thể thu hồi quyền truy cập ngay khi nhân sự hoặc học sinh rời hệ thống không

·         Nếu tài khoản quản trị bị chiếm quyền, phạm vi thiệt hại tối đa là gì

·         Khi dịch vụ bị tấn công hoặc ngừng hoạt động, dữ liệu và hoạt động dạy học được khôi phục bằng cách nào

ISO/IEC 27001:2022 cũng đặt quản lý rủi ro đối với thông tin vào trung tâm của hệ thống quản lý an toàn thông tin, thay vì xem bảo mật như một tập hợp các tính năng riêng lẻ.

Điểm cần tránh là coi chứng nhận của nhà cung cấp như bằng chứng rằng sản phẩm tự động an toàn trong mọi cách sử dụng. Chứng nhận có thể hỗ trợ đánh giá, nhưng rủi ro cuối cùng còn phụ thuộc dữ liệu mà trường đưa vào, cấu hình, tích hợp, quyền truy cập và quy trình vận hành của chính trường.

Đánh giá tác động đối với người học và quá trình giáo dục

Rủi ro công nghệ giáo dục không chỉ là mất dữ liệu. Công nghệ có thể vận hành đúng kỹ thuật nhưng vẫn gây tác động tiêu cực đến học sinh.

Ba nhóm cần đánh giá riêng là an toàn người dùng, công bằng tiếp cận và tác động sư phạm.

Kiểm tra khả năng tiếp cận

Nếu một nền tảng trở thành công cụ bắt buộc trong khóa học, người không thể sử dụng giao diện đó có thể mất khả năng tiếp cận chính hoạt động học tập.

WCAG 2.2 của W3C cung cấp các tiêu chí kiểm thử khả năng tiếp cận ở ba mức A, AA và AAA, bao phủ nhu cầu của nhiều nhóm người khuyết tật. W3C khuyến nghị sử dụng WCAG 2.2 khi phát triển hoặc cập nhật chính sách web accessibility.

Vì vậy, đánh giá không nên dừng ở tuyên bố “hỗ trợ accessibility”. Cần thử trực tiếp các luồng quan trọng như đăng nhập, xem nội dung, làm bài, nộp bài, nhận phản hồi và yêu cầu hỗ trợ với bàn phím, trình đọc màn hình và các phương thức truy cập phù hợp với người học thực tế.

Kiểm tra rủi ro bất bình đẳng

Công nghệ có thể vô tình đặt một nhóm học sinh vào thế bất lợi nếu cần thiết bị mới, đường truyền ổn định, tài khoản cá nhân, kỹ năng số cao hoặc môi trường học tại nhà mà không phải ai cũng có.

Do đó, cần hỏi một câu rất thực tế: nếu học sinh không thể dùng công nghệ trong điều kiện lý tưởng, họ có còn hoàn thành nhiệm vụ học tập bằng phương án hợp lý khác không?

Nếu câu trả lời là không, rủi ro tiếp cận phải được xem là rủi ro triển khai chứ không phải vấn đề hỗ trợ sau triển khai.

Kiểm tra tác động sư phạm

Một công nghệ giáo dục chỉ đáng triển khai khi lợi ích dự kiến có thể quan sát hoặc đo lường được.

Không nên dùng các mục tiêu mơ hồ như “tăng tương tác” nếu tổ chức không xác định tương tác nào có giá trị. Thay vào đó, có thể đặt KPI gắn với nhiệm vụ cụ thể, chẳng hạn tỷ lệ hoàn thành, thời gian giáo viên dành cho một quy trình, tỷ lệ lỗi, chất lượng phản hồi hoặc kết quả của một hoạt động học đã xác định trước.

Điểm quan trọng là không nhầm mức sử dụng với hiệu quả giáo dục. Học sinh đăng nhập nhiều hơn không tự động chứng minh học tốt hơn.

Nếu sử dụng AI hoặc công nghệ tạo sinh, rủi ro còn bao gồm nội dung sai, thiên lệch, nội dung không phù hợp độ tuổi và suy giảm quyền chủ động của người học. UNESCO khuyến nghị cách tiếp cận lấy con người làm trung tâm, chú trọng quyền riêng tư, tính phù hợp với độ tuổi, công bằng, hòa nhập và việc thẩm định công cụ trước khi sử dụng trong giáo dục.

Vì thế, đầu ra của công nghệ càng có ảnh hưởng trực tiếp đến học sinh, mức giám sát của con người càng cần cao.

Kiểm tra nhà cung cấp và rủi ro phụ thuộc

Nhiều rủi ro chỉ xuất hiện sau khi trường đã phụ thuộc vào sản phẩm: giá thay đổi, chức năng bị loại bỏ, API thay đổi, công ty ngừng dịch vụ hoặc dữ liệu không thể chuyển sang hệ thống khác.

Đây là lý do đánh giá nhà cung cấp phải xem cả khả năng rời bỏ sản phẩm, không chỉ khả năng bắt đầu sử dụng.

Trước khi ký hợp đồng hoặc triển khai diện rộng, cần làm rõ:

·         Ai sở hữu dữ liệu do người dùng tạo ra

·         Nhà cung cấp có sử dụng dữ liệu để quảng cáo, huấn luyện mô hình hoặc phát triển sản phẩm không

·         Có nhà thầu phụ nào được tiếp cận dữ liệu không

·         Dữ liệu được lưu ở đâu

·         Chính sách lưu giữ và xóa dữ liệu như thế nào

·         Có thể xuất dữ liệu ở định dạng sử dụng được hay không

·         Khi chấm dứt hợp đồng, dữ liệu được trả lại và xóa trong điều kiện nào

·         Điều gì xảy ra nếu nhà cung cấp ngừng dịch vụ

·         Thời gian hỗ trợ và xử lý sự cố có được cam kết không

·         Những thay đổi lớn về điều khoản hoặc chức năng được thông báo bằng cách nào

Bộ Giáo dục Hoa Kỳ cung cấp cả tài liệu hướng dẫn và checklist điều khoản dịch vụ nhằm giúp cơ sở giáo dục xem xét cách nhà cung cấp thu thập, sử dụng và truyền thông tin người dùng trước khi quyết định sử dụng một dịch vụ trực tuyến.

Một hiểu nhầm cần tránh là cho rằng sản phẩm của công ty lớn luôn có rủi ro thấp hơn. Quy mô nhà cung cấp có thể cải thiện một số năng lực vận hành, nhưng không giải quyết tự động các vấn đề như mục đích sử dụng dữ liệu, vendor lock-in, mức phù hợp với học sinh hay sự phụ thuộc vào kết nối internet.

Chấm điểm rủi ro và đặt ngưỡng quyết định

Sau khi nhận diện rủi ro, tổ chức cần chuyển chúng thành một risk register để so sánh và ra quyết định.

Một mô hình đơn giản có thể sử dụng hai thang 1–5:

Điểm rủi ro = Khả năng xảy ra × Mức độ tác động

Khi đó điểm tổng nằm trong khoảng 1–25. Đây là thang quản trị nội bộ, không phải một ngưỡng chuẩn bắt buộc của ISO hay NIST; mỗi tổ chức cần hiệu chỉnh theo bối cảnh và mức chấp nhận rủi ro của mình.

Ví dụ:

Sau khi áp dụng biện pháp kiểm soát, cần chấm lại rủi ro còn lại. Đây mới là con số phục vụ quyết định triển khai.

ISO 31000 mô tả quản trị rủi ro như một quá trình gồm nhận diện, phân tích, đánh giá, xử lý, giám sát và trao đổi về rủi ro. Điều này nhấn mạnh rằng việc “có danh sách rủi ro” chưa đủ; tổ chức phải quyết định rủi ro nào được chấp nhận, rủi ro nào phải giảm và rủi ro nào khiến dự án không được tiếp tục.

Không nên chỉ dùng tổng điểm để quyết định. Một số rủi ro nên trở thành điều kiện chặn dù xác suất được ước lượng thấp, chẳng hạn:

·         Không xác định được dữ liệu học sinh được sử dụng vào mục đích gì

·         Không có cơ chế xóa hoặc trả lại dữ liệu

·         Không đáp ứng nghĩa vụ pháp lý áp dụng

·         Công nghệ bắt buộc nhưng một nhóm người học không thể tiếp cận

·         Một quyết định có hậu quả cao được tự động hóa mà không có cơ chế giám sát hoặc kháng nghị

·         Không có phương án duy trì hoạt động giáo dục khi dịch vụ thất bại

Cách này tránh tình trạng một rủi ro nghiêm trọng bị “trung bình hóa” bởi nhiều tiêu chí ít quan trọng hơn.

Thử nghiệm giới hạn trước khi triển khai diện rộng

Đánh giá trên giấy không thể phát hiện toàn bộ rủi ro vận hành. Vì vậy, bước cuối trước triển khai rộng nên là một pilot có giới hạn.

Pilot không phải phiên bản thu nhỏ của rollout. Mục tiêu của nó là kiểm chứng các giả định rủi ro.

Hãy xác định trước:

·         Nhóm người dùng và thời gian thử nghiệm

·         Dữ liệu nào được phép sử dụng

·         Chức năng nào được bật

·         Chỉ số thành công

·         Sự cố phải ghi nhận

·         Ngưỡng khiến pilot tạm dừng

·         Người có quyền ra quyết định dừng

·         Quy trình hoàn nguyên nếu thử nghiệm thất bại

Ví dụ, nếu giả định rằng công nghệ giúp giáo viên giảm thời gian thực hiện một tác vụ, pilot phải đo thời gian trước và sau. Nếu rủi ro chính là học sinh khó sử dụng, phải thu thập dữ liệu lỗi và yêu cầu hỗ trợ theo nhóm người dùng. Nếu rủi ro chính là AI đưa ra nội dung không chính xác, cần lấy mẫu đầu ra và đánh giá tỷ lệ lỗi theo một tiêu chí đã định nghĩa trước.

Quan trọng hơn, dữ liệu pilot cần được dùng để cập nhật risk register. Rủi ro có xác suất cao hơn dự kiến phải được chấm lại; biện pháp kiểm soát không hoạt động phải được thay thế; rủi ro mới phát hiện phải được đưa vào quyết định cuối cùng.

Quản trị rủi ro vì vậy không kết thúc vào ngày sản phẩm được phê duyệt. NIST AI RMF nhấn mạnh quản lý rủi ro phải diễn ra liên tục trong suốt vòng đời hệ thống, còn NIST CSF 2.0 bao gồm cả phát hiện, ứng phó và phục hồi sau khi công nghệ đã đi vào sử dụng.

Ra quyết định triển khai dựa trên rủi ro còn lại

Một quyết định tốt không nhất thiết là “triển khai” hoặc “không triển khai”. Có ít nhất bốn kết quả hợp lý:

·         Triển khai khi rủi ro còn lại nằm trong giới hạn chấp nhận và các kiểm soát đã hoạt động

·         Triển khai có điều kiện khi phải duy trì một số giới hạn như nhóm người dùng, dữ liệu hoặc chức năng

·         Tiếp tục pilot khi bằng chứng chưa đủ để kết luận

·         Không triển khai khi tồn tại rủi ro không thể kiểm soát hoặc lợi ích không đủ bù đắp chi phí và nguy cơ

Trách nhiệm quyết định cũng không nên đặt hoàn toàn lên bộ phận IT. Công nghệ giáo dục tác động đồng thời tới dữ liệu, dạy học, quyền của người học và vận hành, vì vậy đánh giá phù hợp thường cần đại diện từ chuyên môn giáo dục, CNTT hoặc an ninh, quản trị dữ liệu hoặc pháp lý, giáo viên và nhóm người dùng chịu tác động.

Điều quan trọng nhất là giữ lại bằng chứng cho quyết định: công nghệ được phê duyệt cho mục đích nào, dựa trên giả định nào, với kiểm soát nào và khi nào phải đánh giá lại.

Một sản phẩm thay đổi điều khoản, thêm chức năng AI, bắt đầu xử lý loại dữ liệu mới hoặc chuyển sang một use case khác về bản chất cần được đánh giá lại, thay vì mặc nhiên dựa vào phê duyệt cũ.

Đánh giá rủi ro công nghệ giáo dục hiệu quả là quá trình nối liền ba câu hỏi: dữ liệu và hệ thống có được bảo vệ không, người học có thể bị ảnh hưởng như thế nào, và tổ chức có đủ khả năng kiểm soát công nghệ trong vận hành thực tế hay không.

Thay vì tìm một sản phẩm “không có rủi ro”, cơ sở giáo dục nên xác định rủi ro nào có thể chấp nhận, rủi ro nào cần kiểm soát và rủi ro nào phải chặn triển khai. Bắt đầu bằng phạm vi sử dụng rõ ràng, lập risk register, kiểm tra dữ liệu và người dùng, đánh giá nhà cung cấp, đặt ngưỡng quyết định rồi chạy pilot có tiêu chí dừng sẽ tạo ra cơ sở chắc chắn hơn nhiều so với việc phê duyệt dựa trên tính năng hoặc danh tiếng sản phẩm.

Cách tiếp cận này cũng phù hợp với nguyên tắc quản trị rủi ro hiện đại: rủi ro không được xử lý một lần rồi bỏ qua, mà phải được nhận diện, đo lường, kiểm soát và theo dõi trong toàn bộ vòng đời công nghệ.

Có cần đánh giá lại một công nghệ đã được trường khác sử dụng rộng rãi không?

Có. Việc một công nghệ được sử dụng rộng rãi chỉ là một tín hiệu tham khảo. Rủi ro phụ thuộc vào dữ liệu, nhóm người dùng, tích hợp, mục đích sử dụng và quy định áp dụng tại chính tổ chức của bạn.

Pilot bao nhiêu người thì đủ để đánh giá rủi ro?

Không có một cỡ mẫu chung phù hợp cho mọi công nghệ. Pilot cần đủ để kiểm tra các kịch bản rủi ro đã xác định và có đại diện của những nhóm người dùng có thể chịu tác động khác nhau. Với rủi ro hiếm nhưng hậu quả nghiêm trọng, pilot nhỏ cũng không thể chứng minh rằng rủi ro không tồn tại.

Có thể sử dụng một điểm tổng duy nhất để quyết định triển khai không?

Không nên. Điểm tổng giúp ưu tiên rủi ro, nhưng các vấn đề pháp lý, quyền riêng tư, an toàn hoặc khả năng tiếp cận nghiêm trọng nên có điều kiện chặn riêng. Nếu chỉ cộng hoặc trung bình điểm, một rủi ro rất nghiêm trọng có thể bị che khuất bởi nhiều tiêu chí ít quan trọng.

Khi nào cần đánh giá rủi ro lại sau triển khai?

Nên đánh giá lại khi use case thay đổi, xuất hiện loại dữ liệu mới, nhà cung cấp thay đổi điều khoản hoặc nhà thầu phụ, có chức năng mới ảnh hưởng đến quyết định giáo dục, xảy ra sự cố đáng kể hoặc dữ liệu vận hành cho thấy các giả định ban đầu không còn đúng.